IESG Narrative Minutes

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

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

Corrections from: Pasi, Dan, Ross, Magnus

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. Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (Proposed Standard)
    draft-ietf-pce-of-06.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-01-15]:
      Section 4., paragraph 7: "Objective Function Code: 2 (suggested value, to be assigned by IANA); Name: Minimum Load Path (MLP); Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi) / R(Lpi), i=1...K } ) is minimized."
      DISCUSS: I may be missing something, but this definition looks iffy. It subtracts the normalized value "r(Lpi) / R(Lpi)" from the absolute value "R(Lpi)" - what's the unit/meaning of the resulting value? Do you maybe mean "((R(Lpi) - r(Lpi)) / R(Lpi)"? In that case, the name should reflect that this is the "normalized MLP". Or is the intent that "load" implies normalization?
      Comment [2009-01-15]:
      Section 4., paragraph 4: "- residual bandwidth on link L is denoted r(L); - maximum reservable bandwidth on link L is denoted R(L)."
      I assume that r(L) is the residual bandwidth that is available for reservation and not the instantaneous available capacity on a link, correct?
      Section 5., paragraph 3: "Type 5 (suggested value to be assigned by IANA) : Load of the most loaded link."
      Similar to my previous comment, does load here refer to the (normalized) amount of reserved capacity, or to actual instantaneous load levels? If the latter, what are the timing/accuracy bounds on that information, and how are they guaranteed?
      Document needs to be spell-checked.
    2. Magnus Westerlund: Comment [2009-01-14]: The abstract is fairly long and seems to be more an introduction than a abstract.
      Section 6.1: One of the data entries of the PCE Objective Function registry is Defining RFC. Considering that you have FCFS policy that allow any registrations then "Defining RFC" may not be the best column name. Reference and contact Person seems to be what should be present.
      I would also note that IETF consensus does not longer exist as policy in RFC 5226, it is called IETF Review instead.

    Telechat:

  2. Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol (Proposed Standard)
    draft-ietf-pce-dste-02.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-01-14]: Title and abstract spell diff-serv differently: which is right?
    2. Tim Polk: Comment [2009-01-14]: Section 3.3, paragraph 6 suggest the following rewording:
      • OLD
        A PCE that recognizes the CLASSTYPE object finds that P flag is not set in the CLASSTYPE object, it MUST send PCE error message towards the sender with the with the error type and error value specified in [PCEP-ID].
      • NEW
        A PCE that recognizes the CLASSTYPE object, but finds that the P flag is not set in the CLASSTYPE object, MUST send a PCE error message towards the sender with the error type and error value specified in [PCEP-ID].

    Telechat:

  3. Softwire Hub & Spoke Deployment Framework with L2TPv2 (Proposed Standard)
    draft-ietf-softwire-hs-framework-l2tpv2-10.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-01-14]: Very clear document. Two minor comments:
      Section 1., paragraph 1: "The Softwires Working Group has selected Layer Two Tunneling Protocol version 2 (L2TPv2) as the phase 1 protocol to be deployed in the Softwire "Hubs and Spokes" solution space. This document describes the framework for the L2TPv2 "Hubs and Spokes" solution, and the implementation details specified in this document should be followed to achieve interoperability among different vendor implementations."
      Referring to WGs and their decision process in RFCs isn't terribly useful, because WGs are ephemeral. I'd suggest to rephrase this to talk about the technology itself.
      Section 4., paragraph 0: "4. Standardization Status; This section groups various Internet standards documents and other publications used in Softwires.
      I don't understand the purpose of this section. Is this supposed to be a reading list of related work, provided for the convenience of implementors? If so, the section title is confusing.
    2. Pasi Eronen: Discuss [2009-01-15]: I have reviewed draft-ietf-softwire-hs-framework-l2tpv2-10, and found it surprisingly easy to understand, and very clearly written. I have a couple of (mostly minor) concerns that I'd like to discuss before recommending approval of the document:
      - L2TP runs over UDP in a rather strange way, and the SCCRP message (reply from SC to SI) can come from different IP address and port than where the SCCRQ (1st message from SI to SC) was sent to. This obviously doesn't work with NATs that do "Address-Dependent Filtering" or "Address and Port-Dependent Filtering" (in RFC 4787 terminology). Should this document say something about the situation? Or even mandate that the addresses/ports in SCCRP must be the addresses/ports n SCCRQ reversed? (This issue is mentioned in the security requirements draft when talking about IPsec, as it complicates IPsec interaction -- but it applies even when not using IPsec).
      - Figures 9 and 10 should also show the IPsec-related steps (marked as "Optional").
      - The details of how RFC43xx IPsec is used to protect L2TP are in the softwire-security-requirements draft -- that probably should be a normative reference? (I'm assuming the intent is that the security-requirements draft meets the "For IPsec, default profiles must be defined" requirement from RFC 4925).
    3. Russ Housley: Discuss [2009-01-12]: The email thread discussing the Last Call comments raised by David Black in his Gen-ART Review indicate that a draft -11 will get needed to resolve the comments. That revised draft has not been posted yet.
    4. Dan Romascanu: Discuss [2009-01-15]:
      1. It is not clear what is the scope of section 4 - Standardization Status. Are all the RFCs listed in this section required for the interoperability and correct operation of Softwire implementations?
      2. Section 4.3 makes reference to two RFCs (1471, 1473) that include MIB documents written in SMIv1. The use of SMIv1 is allowed under certain conditions... Were these aspects checked wrt. to RFC 1471 and RFC 1473?
      Also related to the same two RFCs - the informational model described there refers to a version of PPP which was sinced updated by RFC 1548 and then by RFC 1661. Is this information model still valid?
      3. Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggests implementation of documents that are currently still Internet Drafts.
      Section 8 updates several existing RADIUS standards RFCs, including:
      • RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present.
      • RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes.
      • RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses).
      Is this really appropriate for a framework document?
      From draft-stevant-software-accounting-01.txt: "A RADIUS accounting entry, as defined in [RFC2867], also includes the NASIPAddress attribute, which gives the IP address of the NAS used as the softwire endpoint. Based on this information, an operator can decide if this softwire is based on IPv4 or IPv6. In the case of provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires, the nature of the traffic reported in the accounting information depends of the address family of NASIPAddress (if NASIPAddress is IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted traffic is IPv4). However, this solution requires extra checking when building accounting report and obviously does not work in case of IPvX over IPvX softwires."
      8.1. Softwire Endpoints
      8.1.1. IPv6 Softwires
      If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message.
      If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs.
      If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements.
      The above paragraph defines new interpretations of these attributes.
      8.1.2. IPv4 Softwires
      If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address.
      If the Framed-IP-Address attribute is not present and the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option.
      The above paragraph defines new interpretations of these attributes.
      8.2. Delegated Prefixes
      8.2.1. IPv6 Prefixes
      If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user.
      Interaction between RADIUS, PPP and DHCPv6 server may follow the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server.
      The above paragraph makes what would appear to be a normative reference to an I-D - however this document is listed as informational reference.
      8.2.2. IPv4 Prefixes
      The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator.
      The above paragraph defines new interpretations of these attributes.
      Comment [2009-01-15]:
      1. 4.3. Authentication Authorization Accounting
      RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865].
      Updated by RFC2868, RFC3575, RFC5080.
      2. Please avoid using the acronym OAM for Operations and Management. OAM stands for too many things that are close but not the same, and we intent to start recommending that the acronyms are used in the IETF in a consistent manner. Section 2.7 is OK, just get rid of the acronyms.

    Telechat:

  4. Layer Two Tunneling Protocol - Setup of TDM Pseudowires (Proposed Standard)
    draft-ietf-l2tpext-tdm-06.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-01-15]: Section 1: "signaling packets). However, the order of the CESoPSN Control Word"
      The acronym needs to be expanded.
    2. Lars Eggert: Comment [2009-01-15]:
      Section 1., paragraph 3: "Setup and maintenance of TDM PWs in MPLS networks using LDP is described in []."
      Missing reference.
      Section 1., paragraph 2: "Setup of structure-aware TDM pseudowires using encapsulations"described in [RFC5087] has been left for further study."
      In that case, the document title should reflect that. Maybe "Layer Two Tunneling Protocol - Setup of Structure-Agnostic TDM Pseudowires"? The RFC Editor will also likely ask you to expand the TDM acronym in the title (and many of the other acronyms you're using.)
    3. Pasi Eronen: Discuss [2009-01-14]: I have reviewed draft-ietf-l2tpext-tdm-06. Overall, the document looks good, but I have the following concerns that I'd like to discuss before recommending approval of the document:
      - A quick question about the "Bit Rate" field of TDM PW AVP: other related RFCs (RFC 5287, 4842) use a 32-bit field for bit rate, and a 16-bit field can't express a bit rate larger than ~4 Gbps. Is this enough?
      - Section 4 says the IANA policy for unassigned values is "Expert Review", but does not list the registries IANA is supposed to create.
      - It seems RFCs 4553 and 5086 should be normative references (they describe e.g. the packet formats used, so they're not just optional background information). RFC 5086 would be a downref.
      Comment [2009-01-14]: Section 1 says "Setup and maintenance of TDM PWs in MPLS networks using LDP is described in []"
      -- this seems to be missing the actual reference.
    4. Magnus Westerlund: Comment [2009-01-13]: There is quite a lot of non-expanded acronyms in the initial part of the document.
      Note that there is an acronym overloading here with the word (AVP) as that has one meaning in RTP talk (Audio/video Profile) and another in this document. So RTP AVP in section 2.2 has the potential to be somewhat confusing.

    Telechat:

  5. A Protocol for Remotely Managing Sieve Scripts (Proposed Standard)
    draft-ietf-sieve-managesieve-06.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-15]: When I try to compile the ABNF with Bill's ABNF parser, I get an error here:
      command-havespace / /
      This seems to be a mistake.
    2. Lars Eggert: Comment [2009-01-15]:
      Section 1.9., paragraph 0: "1.9. Link Level; The ManageSieve protocol assumes a reliable data stream such as that provided by TCP."
      I think you want to make TCP support for ManageSieve REQUIRED. (Also, nit, "Link Level" isn't the greatest section name for this - maybe "Transport"?)
      Section 1.9., paragraph 1: "When TCP is used, a ManageSieve server typically listens on port 2000. [[anchor7: IANA registration of port 2000 is pending.]]"
      Port 2000 is unavailable, but I see Chris is holding the DISCUSS.
    3. Pasi Eronen: Discuss [2009-01-15]: (updated discuss)
      It seems the Security Considerations text should say something about the TRANSITION-NEEDED response?
      IANA Considerations: should you ask IANA to add "sieve" to the "GSSAPI/Kerberos/SASL Service names" registry?
      Comment [2009-01-15]: (empty)
    4. Chris Newman: Discuss [2009-01-12]: Holding discuss for IANA issue -- port 2000 is already registered; Sieve needs to pick a different port.

    Telechat:

2.1.2 Returning Items

  1. IEEE 802.21 Mobility Services Framework Design (MSFD) (Proposed Standard)
    draft-ietf-mipshop-mstp-solution-11.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-09-25]: Last Edited Date: 2008-09-25
      Section 6.1., paragraph 4: "In terms of dealing with short messages, TCP has the capability to concatenate very short messages in order to reduce the overall bandwidth overhead. However, this reduced overhead comes at the cost of additional delay to complete an MIH transaction, which may not be acceptable for CS and ES services."
      The only delay with TCP (assuming Nagle is turned off) is the connection setup delay, i.e., a delay on the very first MIH exchange.
      Section 6.2., paragraph 1: "Therefore a burst of either short CS/ES messages or long IS message exchanges (in the case where multiple MIH nodes request information) may lead to network congestion. While the built-in rate-limiting controls available in TCP may be well suited for dealing with these congestion conditions, this may result in large transmission delays that may be unacceptable for the timely delivery of ES/CS messages.
      TCP backs off if there is packet loss, and yes, performance may degrade. But UDP is no magic bullet, either - UDP packets in such scenarios are lost in the same way as TCP packet, and delivery over UDP is unlikely to be more timely than with TCP.
      Section 6.3., paragraph 3: "An MIH message is retransmitted if its corresponding MIH ACK is not received by the generating node within a timeout interval set by the MIHF. This approach does not include an exponential backoff and therefore tends to degrade more gracefully than TCP when the packet loss rate becomes large, in the sense that the expected delay does not increase exponentially. The number of retransmissions is limited, which reduces head-of-line blocking of other MIH messages, but this can cause important ES/CS messages to be lost. The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s. No backoff mechanism is specified."
      I don't buy this. If you wait 10s before the first retransmit and then try another one after 20s, TCP will have long retransmitted the lost packets, because its RTO is based on the RTT, which is typically much less than 10s. UDP will only be faster if much more aggressive timers are used here, which is problematic. I'd like to request that the text around what timers values are permissible be tightened using 2119 language. (I believe this is part of Magnus' discuss, so I'll leave this as a comment for now. I may upgrade this to a discuss if Magnus' discuss doesn't include this bit.)
      Section 6., paragraph 1: "Given the reliability requirements for the MIH transport, it is assumed in this discussion that the MIH ACK mechanism is to be used in conjunction with UDP, while it is preferred to avoid using MIH ACKs with TCP since TCP includes acknowledgement and retransmission functionality.
      Given the reliability requirements, shouldn't this text REQUIRE MIH ACKs with UDP and say they MUST NOT be used with TCP? (I can't come up with a reason to permit anything else.)
      Section 6.3., paragraph 2: "If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs."
      See above, I think your reliability requirements make this a MUST.
      Section 6.1., paragraph 5: "The use of the PUSH bit can alleviate this problem by triggering transmission of a segment less than the SMSS."
      The PUSH bit is not under the control of an application that uses TCP. I believe you mean that the Nagle algorithm (RFC896) should be disabled.
      Section 6.2., paragraph 3: "If MIHF knows the RTT, the rate can be based upon this"
      How?
      Section 6.3., paragraph 1: "For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly with increased packet loss."
      And that is a *feature* - it's why Internet congestion control works.
    2. Pasi Eronen: Discuss [2008-09-25]: (Updated discuss)
      I have read draft-ietf-mipshop-mstp-solution-06. It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't read), but I have the following concerns that I'd like to discuss:
      The document currently says that TLS can be used, but is silent about the details. For example, how authentication and authorization are done -- e.g. are some fields in certificates expected to match some fields in the MIH protocol? What the certificates are expected to look like? How this interacts with the discovery mechanisms (e.g. NAPTR specs recommend that the certificate contains the *input* to NAPTR processing, not the output -- but some specs have chosen otherwise)? What the mandatory-to-implement parts of TLS are?
      In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem inconsistent (MoSV is defined as "anything that isn't a MoSh", and MoS3 is defined as "anything that isn't a MoSh or MoSV" -- but that would seem to make MoS3 an empty set).
      The document assumes that NAI can be used to identify a MIHF endpoint; but usually NAI identifies a user account which can be used simultaneously on multiple hosts (each of which would be a separate MIHF endpoint).
      It seems that both MIH-over-TLS-over-TCP and MIH-over-TCP use the same port number (likewise for DTLS/UDP case) -- how does the recipient distinguish which is being used? Perhaps the MIH protocol has functionality like "STARTTLS"?
      draft-ietf-mipshop-mos-dns-discovery-02 supports MIH-over-SCTP as well, but this document doesn't -- should they be aligned, and if so, which one needs to be changed?
      The examples use real domain names (which are owned by someone). I'd suggest changing to RFC 2606 names (example.com etc.), unless there are really good reasons not to do so.
    3. Russ Housley: Comment [2008-09-24]: David Black did a Gen-ART Review during Last Call. Please respond to the concerns raised in this review.
    4. Chris Newman: Comment [2008-10-16]: I support Pasi's discuss. TLS has shown to be a deployable privacy solution in the real world. In addition to privacy, it includes authentication support that works in some scenarios or when application protocols that caused real deployment problems and had to be corrected (the most notable is allowing "STARTTLS" to be advertised as a capability by a server even if no server certificate is installed).
      I strongly recommend getting this right early rather than botching it and having to work around bad deployment practices.
    5. Tim Polk: Comment [2008-09-25]: [I have cleared my discuss and moved this to a comment after discussion with the sponsoring AD...]
      Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?)
      Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?
    6. David Ward: Comment [2008-09-25]: I will let the others hold the discuss but, they must be cleared.
    7. Magnus Westerlund: Comment [2008-11-04]: (empty)

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol (Informational)
    draft-ietf-ipdvb-sec-req-09.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-01-15]:
      Appendix A talks about modeling DBV link layer security with a number of modules, including a security policy database (SPD) that may resemble a similar functionality in IPsec.
      I wanted to note that traditionally link layer security has been operated using far simpler policy mechanisms that exists at the IP layer. Typically, security is either applied or not applied; some form of algorithm selection is of course needed for algorithm agility.There are many good reasons for these simple policies, e.g., avoiding complexity, the endpoints stay the same (host -> AP), the endpoints are known to support the mandatory link layer security features, etc.
      I would suggest that the same may apply for DVB as well.
    2. Russ Housley: Comment [2009-01-12]: Please consider the comments made by Vijay Gurbani in the Gen-ART Review that he posted on 28-Nov-2008.
      In S4, requirements 2-5 have a normative strength of OPTIONAL. While I am not trying to second guess the decision reached by the WG in assigning this normative strength, I am just curious why the strength was not at least a SHOULD (or RECOMMENDED)? These seem like good requirements to have, and keeping them OPTIONAL effectively implies that very few vendors, if any, will implement them.
      In Abstract: s/a range of services/a variety of services/ (reason: "range" is used in the line above as well.)

    Telechat:

  2. MANET Extension of OSPF using CDS Flooding (Experimental)
    draft-ietf-ospf-manet-mdr-04.txt
    Token: David Ward
    Extracted from Balloting:
    1. (none)

    Telechat:

  3. OSPF MPR Extension for Ad Hoc Networks (Experimental)
    draft-ietf-ospf-manet-mpr-03.txt
    Token: David Ward
    Extracted from Balloting:
    1. (none)

    Telechat:

  4. Extensions to OSPF to Support Mobile Ad Hoc Networking (Experimental)
    draft-ietf-ospf-manet-or-01.txt
    Token: David Ward
    Extracted from Balloting:
    1. Russ Housley: Discuss [2009-01-12]: Ben Campbell provided significant comments in a Gen-ART Review that was posted on 2008-12-23. There has been no response to this review. Please respond to these Last Call comments.
      The Gen-ART review can be found at: http://www.softarmor.com/rai/temp-gen-art/draft-ietf-ospf-manet-or-01-campbell.txt

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions (Informational)
    draft-mammoliti-l2tp-accessline-avp-05.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-14]: This is a good document and was about to vote Yes. However, there were a couple of minor unclear points which I believe should be corrected before the document moves forward, so that the reader can unambiguously understand what the spec means:
      1. Please provide a definition of attainable and maximum (and how they differ from each other). Presumably maximum refers to a configured per-policy allowable value. Is attainable the value that the physical media etc. allows the user to employ? Can attainable speed be higher than maximum speed?
        It is possible that these are already well defined in the DSLF documents that I did not read. If so, please add an explicit reference from the use of the term to its definition.
      2. It's not clear to me what minimum speeds mean, please define them better. Is a minimum configured speed a policy limit for how much at least should be given to the user? What if the actual data rate is lower?
      3. Please define "interleaving delay".
      4. IANA considerations section should state what the policy is for allocating new enumerated values for AVPs defined in this document (such as ANCP Access Line Type AVP). It is possible that the L2TP documents already have a generic policy for this. If that is the case, please refer to that policy from the IANA considerations section.

      Comment [2009-01-14]: There seems to be duplication between last paragraph of Section 3 and the first paragraph of Section 4. Please reword/move text.
    2. Pasi Eronen: Comment [2009-01-13]: In Section 5.3, "4-octet unsigned integer" should be "8-octet unsigned integer".

    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. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

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. (none)

    1239 EDT break

    1244 EDT back

5. IAB News We can use

  1. Loa: pass
  2. ??: headers and boilerplate?
  3. Loa: not sure, ask Olaf

6. Management Issues

  1. Deleted IPR Statements (Russ Housley)

    Telechat:

  2. IESG Statement regarding chartered work overcome by events before IESG consideration (Ron Bonica)

    Telechat:

  3. Draft Statement on BCP Status for Examples (Dan Romascanu)

    Telechat:

  4. 5378 (Cullen)

    Telechat:

  5. Retreat (came up)

    Telechat:

7. Agenda Working Group News

1354 EDT Adjourned

Valid HTML 4.01 Strict