IESG Narrative Minutes

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

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

Corrections from: Russ, Magnus, Jari, Dan

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. CAPWAP Access Controller DHCP Option (Proposed Standard)
    draft-ietf-capwap-dhc-ac-option-01.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-09-25]: FYI: I have question out to my DHCP experts on why on the IPv6 side we return options without the client asking for them -- other documents have done this differently.
    2. Discuss [2008-09-25]: John Brzozowski (one of the DHC WG chairs) said this:
      "In short a DHCPv6 server should ONLY send options requested by the client. There was some debate about this a while back and the end result, if I recall correctly, is what I stated above. The thinking here is/was why would a server transmit an option(s) if the client has not requested it. Further, what value might there be sending an option to a client that it did not explicitly request and subsequently might not know how to parse or process."
      However, also note the following excerpt from RFC3315 section 17.2.2. Creation and Transmission of Advertise Messages. This text appear in several area of RFC3315:
      "The server includes options the server will return to the client in a subsequent Reply message. The information in these options may be used by the client in the selection of a server if the client receives more than one Advertise message. If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. The server must be aware of the recommendations on packet sizes and the use of fragmentation in section 5 of RFC 2460."
      The above seems to clearly suggest that the server MAY legally transmit options to client(s) that were not specifically requested in the ORO.
      My advice is to require the DHCPv6 clients in this case to add the requested option to the DHCPv6 ORO.

    Telechat:

  2. ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (Proposed Standard)
    draft-ietf-ccamp-isis-interas-te-extension-04.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-09-25]: It would be good to have the usual pointer in Security Considerations: "For a discussion of general security considerations for IS-IS see [RFC3567bis]" (or something like that)
    2. Tim Polk: Discuss [2008-09-25]: This is a discuss discuss.
      This document permits a subset of sub-TLVs from RFC 3784 and [ISSI-TE-V3] "and other documents" to appear in the new top-level TLV "Inter-AS Reachability TLV" (Type 141).
      The subset is specified implicitly ("sub-TLVs ... for describing the TE link"). The only explicit linkage will be that in the IANA registry, where the sub-TLV will be marked as "May be present on TLV 141".
      As a non-routing area reader, I think this is a bit confusing. We will have sub-TLVs that may appear in this new TLV, but no RFC anywhere will specify the linkage. I would have felt more comfortable if we included the initial list of "May be present on TLV 141" in this document. Did this bother anyone else?

    Telechat:

  3. RPCSEC_GSS Version 2 (Proposed Standard)
    draft-ietf-nfsv4-rpcsec-gss-v2-05.txt
    Token: Lars Eggert Note: Document Shepherd: Spencer Shepler (spencer.shepler@gmail.com)
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-09-25]:
      Since GSS-API already supports channel bindings (with some GSS-API mechanisms), it seems we end up with three different ways to do channel bindings in RPCSEC_GSS... The document probably should describe why the existing GSS-API layer channel bindings are not sufficient and give some guidance about their use
      I think the document would also be improved by explicitly noting that a channel (e.g., IPsec or TLS) can have multiple channel bindings with different prefixes (e.g., for TLS we currently have two), and describing how the initiator picks which of them to use (and how this interacts with RGSS2_BIND_CHAN_PREF_NOTSUPP).
    2. Chris Newman: Comment [2008-09-22]:
      Section 3.3, second bullet: I suggest you also reference the IANA registry "Hash Function Textual Names" to help find new hash functions as they're defined.
      General Concern: A test vector or two would greatly improve this document.
    3. Magnus Westerlund: Comment [2008-09-23]: There are no reference to XDR in the first occurrence in section 1.
    4. Tim Polk: Comment [2008-09-25]: I support Pasi's discuss. I have no other objections to the document.
    5. Dan Romascanu: Discuss [2008-09-24]: I do not get a clear understanding from the document about the relation with RFC 2203. From what I get in section 4 the two versions of the protocol can coexist on the wire and a mechanism to negotiate the versions is in place. From the introductory sections I get that the reasons and advantages of using version 2 are limited to specific cases where low level hardware encryption is in place, or to avoid redundancy if encryption takes place at lower layer. What is the operational recommendation for deployment then - always upgrade or only in specific use cases?
      Should not the document header mention Update RFC2203 - when approved?
      Comment [2008-09-24]: The acrnym GSS is never expanded in the document. I suggest to expand it at the first occurence in the Abstract or Introduction section.
    6. Magnus Westerlund: Comment [2008-09-23]: There are no reference to XDR in the first occurrence in section 1.

    Telechat:

  4. Mobility Services Framework Design (MSFD) (Proposed Standard)
    draft-ietf-mipshop-mstp-solution-06.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-09-25]: I refreshed my memory on the previous discussion between transport folks and MIPSHOP, and this is a significant edit of my earlier discuss and comment text. The use of both UDP and TCP by MIH is OK, but I'd like to see stronger text that recommends or even requires which protocol should be used for which messages (namely, UDP for ES/CS messages that are guaranteed to be < 512 bytes and TCP for all IS messages).
      I also have a discuss-discuss, It seems that SCTP (esp. partial reliability SCTP) would be the ideal transport for MIH, given that it was designed especially for telephony-like signaling. The document doesn't even mention SCTP as an option. Has the WG considered SCTP and if yes, why wasn't it chosen?
      Comment [2008-09-25]:
      Section 6.1., paragraph 4: The only delay with TCP (assuming Nagle is turned off) is the connection setup delay
      Section 6.2., paragraph 1: TCP backs off if there is packet loss, and yes, performance may degrade. But UDP is no magic bullet, either - delivery over UDP is unlikely to be more timely than with TCP.
      Section 6.3., paragraph 3: 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.
      Section 6., paragraph 1: Given the reliability requirements, shouldn't this text REQUIRE MIH ACKs with UDP and say they MUST NOT be used with TCP?
      Section 6.3., paragraph 2: See above, I think your reliability requirements make this a MUST.
      Section 6.1., paragraph 5: 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]: It's not really possible to review this in meaningful sense without reading 802.21 itself (which I haven't done yet), but I have the following concerns that I'd like to discuss:
      In Section 2, the definitions of "MoSh", "MoSv", and "MoS3" seem inconsistent (MoSV is defined as "anything that isn't a MoSh", and
      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). How does this work?
      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"? (if so, it should be briefly described here)
      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: Discuss [2008-09-24]: David Black did a Gen-ART Review during Last Call. I have not seen a response to his review. I am especially concerned about two issues raised in this review.
      First, Section 6.3 says: "The default number of retransmissions is set to 2 and retransmissions are controlled by a timer with a default value of 10s." Those values appear to be reasonable. Please say that they SHOULD be used, possibly with some qualification involving network-specific characteristics.
      Second, IS messages are the primary source of large messages, and IS messages do not have tight latency requirements. So, David asks if it is appropriate to say that TCP SHOULD be used for IS messages.
      Comment [2008-09-24]: David Black did a Gen-ART Review during Last Call. Please respond to the concerns raised in this review.
    4. Cullen Jennings: Discuss [2008-09-24]: The document seems to recommend a 24 hour keep alive timer for TCP connections. Most NATs and middle boxes I have seen need something more like 2 hours, however the underlying OS TCP stacks typically do this without people being aware of it. Could the authors have a look and check the document says what they want. I'm OK with 24 hours if that is what people really meant but it surprises me.
    5. Tim Polk: Discuss [2008-09-25]:
      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. Magnus Westerlund: Discuss [2008-09-23]:
      Section 6.3: I am deeply worried over this retransmission scheme. Due to the bad performance I think people will change the retransmission number to a higher value and reduce the timer to a much smaller value. In which case the lack of exponential back-off can have bad effects on the network.
      I haven't looked at the MIH layer and what functions it provide. To give good performance I hope there is the following facilities available:
      - sequence number for duplication and reordering detection
      - possibility to timestamp or at least measure the RTT reasonably
      I know too little about your requirement and capability to give really good recommendations. However, instead of reinventing the wheel why not always use TCP?
      Section 6.4: If the TCP connection goes through a NAT box also that is subject to binding loss. However, the timeouots are much more reasonable. However, issues with NAT traversal using UDP are documented in [I-D.ietf-tsvwg-udp-guidelines]. If the MN has to send keep-alive messages to keep the binding open for MoS -> MN traffic you are going to have to send a lot of traffic.
      I am fumbling in the dark here a bit as I don't understand which usage requirements you have, and how the the deployment model looks and between which nodes you really expect NATs to appear.
      Comment [2008-09-23]:
      Section 6. I assume there is retransmission functionality for non-reliable transports, those really SHOULD NOT be used when sending over reliable transports.
      Section 6.1: Considering NAT traversal and performance implications I think recommending against usage of IP fragmentation is the right one. But that is not knowing which facilities MIH layer fragmentation provides. Can you please clarify this.

    Telechat:

2.1.2 Returning Items

  1. Generalized MANET Packet/Message Format (Proposed Standard)
    draft-ietf-manet-packetbb-15.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-09-24]: I support Lars' comment about multiplexing, but don't think that it is a big enough issue to motivate an abstention. The multiplexing strategy described in Appendix A makes the MANET difficult to implement, but I don't think that it does any real harm to the Internet.
    2. Lars Eggert: Comment [2008-09-23]:
      I still disagree with the design philosophy behind this packet format, but since this isn't actionable this late in the game, I'll abstain.
      I also don't believe the multiplexing and demultiplexing approach in Appendix A is fully thought through, especially in light of the IANA actions for MANET. If all MANET daemons on one node share a port, and if packets destined to that port can contain messages that need to be delivered to different routing daemons (and some that need to be delivered to multiple daemons), who performs this demultiplexing and how?
    3. Chris Newman: Comment [2008-03-12]:
      If msg-hop-count is missing, should it be added if the message is forwarded?
      it would be good to collect or summarize requirements like this into a separate section listing requirements for consumers of the format.
      should state the title of the IANA registry, for example: "MANET Message Types".
      You might want to apply equivalent rules to values 120-127 for things that best appear at the end (e.g. a signature).
      Some design issues that concern me:
      - The format has lots of options.
      - Creating two different ways to encode the same thing is always risky.
      - The TLV index feature is really a layering violation
      - I'm concerned that limiting the sequence number to 16 bits is choosing conciseness over reality.
    4. Dan Romascanu: Comment [2008-01-24]: I am actually wondering whether it would not be better that documents that a Gen-ART (or security, or other) review declare non-fit for IESG discussion first address the review issues and only then be placed on an IESG telechat agenda.
    5. Magnus Westerlund?: Comment [2008-01-24]: This document has so many bugs related its design that it really should go back to the WG for rehashing. Some issue to consider that are evident:
      - Lack of default values for optional fields that in fact seems mandatory
      - Version extension rules lacks requirement on what fields may not be changed when changing version.
      - Unnecessary complexities from lack of willingness to determine what is important and what is not.
      - Message Sequence number with unclear definition where part of the text allows any generation, but with uniqueness and the other talks about wrapping. In other words non combinable properties.
      IESG internal process comment: I have to agree with Dan here. It is the work of the responsible A to not place documents on the IESG agenda that are not ready in the AD's view. That means following up on reviews in WG last call. Yes, in this case the Gen-art review was two days late.

    Telechat:

  2. Representing multi-value time in MANETs (Proposed Standard)
    draft-ietf-manet-timetlv-07.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-06-26]: What makes it hard to read this spec is that the definitions are almost, but not entirely, free of context. A set of addresses is a context for some statement about them. Your specification defines the format of the statement about time, but does not fully define what objects (addresses) it applies to.
    2. Ron Bonica: Discuss [2008-09-24]: The authors generate a new mechanism for representing time, but they never explain the following:
      - why are we constrained to 8 bits
      - if all MANET nodes must have the same value C, why is it included in the calculation?
      - what granularity is required (seconds, milliseconds?)
      - what high and low values must be represented
    3. Lars Eggert: Comment [2008-01-23]: I agree with the gen-art reviewer that the concept of "distance" is not well- explained. I'm also questioning why it makes sense to specify a relatively complex construct such as distance-dependent time in a generic TLV format - is this really common enough across MANET protocols so that it needs to be specified generically?
      Finally, Chris raises a good point - it's unclear why a new fixed-point format is the right thing here, especially since it can only be understood if one knows what "C" is in use. Burning a few more bits and eliminating "C" seems to be the right tradeoff.
    4. Chris Newman: Comment [2008-01-21]: I saw no discussion in this document justifying the complexity of creating a new custom 8-bit floating point number format rather than just using a simple 32-bit integer.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. WebDAV Current Principal Extension (Proposed Standard)
    draft-sanchez-webdav-current-principal-01.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Russ Housley: Discuss [2008-09-24]: Christian Vogt did a (late) Gen-ART Review. I have not seen a response to his review. I would really like to see if the author agrees or disagrees with the technical point that he raises:
      Section 3, 2nd paragraph of "description" field:
      This paragraph specifies the return value for the principal resource in case there are multiple possible values. The return value is in this a case to be freely chosen by the server. Why not return all possible values?
      The disadvantage of returning only a single principal resource value is that it may lead to consistency problems. The paragraph attempts to prevent this by urging servers to /try/ to be consistent. But since consistency cannot be guaranteed, consistency problems may still come up. Always returning all possible values would fix this.
      The authors should consider changing the protocol behavior to always returning all available principal resource values. If there are reasons to restrict the number of values returned to a single one, then these reasons should be explained in section 3 of the document.
      Comment [2008-09-24]: Christian Vogt did a (late) Gen-ART Review. Please respond to the technical and editorial issues raised in this review.

    Telechat:

2.2.2 Returning Items

  1. URI Scheme for GSM Short Message Service (Proposed Standard)
    draft-wilde-sms-uri-16.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-09-25]: I share the issue in 2nd part of Russ's Discuss: I also felt that the document brought in a bit too many details about the processing, formatting, and delivery of SMSes. This RFC does not define how SMSes are sent, it just defines URIs.
    2. Pasi Eronen: Comment [2008-09-24]: I think the document would benefit from including an example with a non-global number (not starting with "+"), since the exact syntax used for them changed very recently (when going from version -15 to -16), and the change might not be obvious to someone who read the old versions.
      Section 1.3.5 would benefit from one sentence saying that when "sms" URI is used in HTML form, the "sms-body" part (if present) is ignored.
    3. Russ Housley: Discuss [2008-09-08]: Miguel Garcia did a Gen-ART Review that revealed two major concerns and some minor ones.
      First, the SMS URI scheme syntax. Notice that <query> can contain the equal sign, I suspect that more than one equal sign might lead to implementation surprises, so the syntax should be adjusted or there should be text to highlight this situation to the reader.
      Second, the scope of this specification is not clear. Are the SMS procedures PART of the scope of this specification?
      Comment [2008-09-08]: Please consider the comments provided by Miguel Garcia in his Gen-ART Review. I have not seen a response to this recent review.
    4. Chris Newman: Discuss [2008-09-22]:
      1. The document needs a normative reference to the HTML 4.01 specification which defines the format for the media type application/x-www-form-urlencoded.
      2. The following text is factually incorrect: "As SMS transport is "out-of-band" as far as normal HTTP over TCP/IP is concerned, this provides a way to fill in forms offline, and send the data without making a TCP connection to the server, as the set-up time, cost, and overhead for a TCP connection are large compared to an SMS message." With my iPhone, there are contexts where SMS is more expensive that HTTP/TCP (e.g. local use if I'm over my prepaid SMS limit). In addition, SMS can be more expensive on the server infrastructure side; a two-way email-to-SMS gateway has to track a large amount of state because SMS has no extension fields for reply gateways. Finally, I observe this contradicts the previous point that SMS "is a major source of revenue" (which implies it's expensive for end-users).
      3. The URI scheme doesn't have an extensibility model as far as I can tell.
      4. You need to discuss how use of comma as a delimiter between addresses interacts with use of comma within a telephone-subscriber (e.g., as the RFC 3966 ABNF permits in the isub= parameter).
      5. While you've defined the charset of the body parameter, the semantics are not defined. Is a newline permitted? If so, how is a newline encoded? Perhaps a reference to 5198 would be helpful?
      6. Why is this "provisional" rather than "Permanent"?
    5. Dan Romascanu: Comment [2008-09-25]: I support the issue raised by Magnus in his DISCUSS.
    6. Magnus Westerlund: Discuss [2008-09-09]: Section 1.3.4 contains example phone numbers that appears to be valid ones. The first I find has or are used by the president of the US. The second seems to point to cellphone in California that aren't listed. As it is known that publication in specification of address or reachability information can result in unwanted traffic I would recommend that these numbers are changed to example ones that are certain for the foreseeable future to don't lead to any individual or organization.

    Telechat:

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. CAPWAP Threat Analysis for IEEE 802.11 Deployments (Informational)
    draft-ietf-capwap-threat-analysis-04.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. (none)

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. MANET Autoconfiguration using Virtual Enterprise Traversal (VET) (Informational)
    draft-templin-autoconf-dhcp-16.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Dan Romascanu: Discuss [2008-09-25]: this is a discuss-discuss for the DNP choice in the note - see the mail thread earlier in the day

    Telechat:

  2. Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs (Informational)
    draft-touch-msword-template-v2.0-07.txt
    Token: Russ Housley
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-09-23]: "This version is intended as an update to RFC3285." Then it needs to have an "Updates: 3285" in the header. I also don't see a reason why this document shouldn't simply obsolete 3285 - is there any functionality lost?

    Telechat:

3.3.2 Returning Items

  1. (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Application-Layer Traffic Optimization (alto)
    Token: Lisa

    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. Softwires (softwire)
    Token: Mark

    Telechat:

    1312 EDT break

    1318 EDT back

5. IAB News We can use

  1. Loa: two short things: RFCed restructuring consensus calls, aim for next Wednesday; second, Routing Research Group, discussion will continue

6. Management Issues

  1. Review of arp-parameters request 2 of 2 [IANA #183428] (Michelle Cotton)

    Telechat:

  2. Large Interim Mtgs (Russ Housley)

    Telechat:

  3. Referencing Non-Standardized Technology in IETF Documents (Dave Ward)

    Telechat:

  4. Designated expert for RFC 5341 [IANA #194783] (Michelle Cotton)

    Telechat:

  5. Review of atom link relations request [IANA #189665] (Michelle Cotton)

    Telechat:

  6. RFC 3932bis (Jari Arkko)

    Telechat:

  7. Approval of IANA expert for STUN (Magnus)

    Telechat:

7. Agenda Working Group News

1418 EDT Went into Executive Session