IESG Narrative Minutes

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

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

Corrections from: Magnus, Pasi, Dan, Russ, Mark

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. RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family (Proposed Standard)
    draft-ietf-avt-rtp-atrac-family-18.txt
    Token: Cullen Jennings Note: Document Shepherd is Tom Taylor.
    Extracted from Balloting:
    1. Russ Housley: Discuss [2008-09-10]: Please consider the comments in Gen-ART Review. This review deserves a response.
    2. Chris Newman: Discuss [2008-09-10]: According to BCP 13 (RFC 4288), the change controller for a standards track media type registration needs to be the standards body itself.
      I recommend splitting author and change controller into separate fields, as both are useful.
    3. Tim Polk: Discuss [2008-09-10]: While the Security Considerations references RFC 4855, it does not directly address some of the aspects that 4855 requires or recommends in the security analysis.
      - A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources.
      I would appreciate it if the authors could review the second list in RFC 4855's security considerations. There may be other relevant issues that I failed to recognize.
    4. Magnus Westerlund: Discuss [2008-09-08]:
      Section 4.5.2: The common solution for this problem has been to either use CNAME bindings to find them or require the same SSRC in both RTP session.
      Section 5.3.1: Can someone please explain how any any other value than 0 can be allowed for an unfragmented frame.
      Section 7.6: Can you please motivate the choice of not talking about this for offer/answer?
      Comment [2008-09-08]: Section 5.3.1: Shouldn't this be defined as "The number of audio frames in this packet are field value + 1"?

    Telechat:

  2. Sieve Email Filtering: Reject and Extended Reject Extensions (Proposed Standard)
    draft-ietf-sieve-refuse-reject-07.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-09-11]: It's a bit strange to have "Updates: 3028" (and a normative reference to RFC 3028) here, since RFC 3028 has been obsoleted by RFC 5228.
      The document says the main difference between 'reject' and 'ereject' is that the latter allows SMTP/LMTP level rejection... but it seems there's another difference: the former talks about sending an MDN, while the latter sends a DSN. I think the document would benefit from short description here, reminding readers that they're not the same thing, and explaining why 'reject' and 'ereject' do things differently.
      From Carl Wallace's SecDir review: Section 2.1: as noted in Tim's DISCUSS, the text about "return-path verification", and discarding the message is that fails, needs some more text explaining this step.
      Comment [2008-09-11]: For reference [Joe-DoS], it'd be nice to have some more bibliographical information (such as name(s) of author(s), and publication venue or URL).
    2. Russ Housley: Discuss [2008-09-10]: Please consider the comments provided by Spencer Dawkins in his Gen-ART Review. I have not seen a response to this review, and it deserves one.
    3. Cullen Jennings: Comment [2008-09-10]: Support Tim's discuss
    4. Chris Newman: Comment [2008-09-04]: I believe this proposal appropriately balances the competing goals of i18n, joe-job defenses and backwards compatibility.
      (if I were aware of a Sun Microsystems economic interest, I would recuse).
    5. Tim Polk: Discuss [2008-09-10]: AFAIK, Carl Wallace's secdir review (submitted 8/14/08) has not received a response, so I integrated his issues into my own review.
      I am particularly concerned about the circumstances for silent discard and conformance requirements for ereject implementations:
      As noted in Carl's secdir review, there is no definition for return-path verification... Is there an accepted algorithm for determining a forged return-path? In the absence of a solid reference, this step is worriesome: silent discard of a legitimate message in a store-and-forward application constitutes an undetectable denial of service attack. If an implementor relies on bad heuristics to make this determination, the results could be ugly.
      To expand on the second issue in Carl's secdir review, the conformance requirements for implementations of ereject are unclear.
      Comment [2008-09-10]:
      • The Security Considerations states: "The Introduction to this document discusses why rejecting messages before delivery is better than accepting and bouncing them." There is no such discussion in the Introduction, just a reference to [Joe-DoS]. I have no idea how to find that document.
      • I thought the security considerations omitted two useful concepts. The first is that upgrading current implementation of reject and use of the new ereject extension will help mitigate some of problems identified in RFC 3834. The second issue is the silent discard problem noted in my discuss. Consider noting that silent discard of legitimate messages constitutes denial of service and that determination of a forged return-path should be performed very carefully
      • From Carl's review: Why is a user interface allowed to silently upgrade from reject to ereject but other implementations are not? Are silent downgrades OK, i.e., for cases where ereject is not supported?
      • from Carl's review: Reason text uses UTF-8 to align an SMTP language extension spec... Should UTF-8 be used here without a normative reference to support it?
      • from Carl's review: There are some unexpanded acronyms, minimally MUA and MTA.

    Telechat:

2.1.2 Returning Items

  1. Session Initiation Protocol Service Examples (BCP)
    draft-ietf-sipping-service-examples-15.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-09-08]: I think people who want to understand how SIP works will find this document very useful.
    2. Cullen Jennings: Comment [2008-03-02]: Questions about call flow in section 2.16. If there was a parallel forking proxy between Alice and Bob, do we end up in a situation where Bill will send a replaces with a to-tag but Alice will not know the to-tag for the dialog?

    Telechat:

  2. Unicast UDP Usage Guidelines for Application Designers (BCP)
    draft-ietf-tsvwg-udp-guidelines-10.txt
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-08-14]: I don't quite understand how the tracker brought this document to the telechat without having Magnus vote "Yes".
    2. Pasi Eronen: Comment [2008-08-11]: There's some repetition of text in Sections 3.1.2 and 3.5, but presumably RFC editor copyediting will take care of that.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Web Distributed Authoring and Versioning (WebDAV) SEARCH (Proposed Standard)
    draft-reschke-webdav-search-18.txt
    Token: Chris Newman Note: AD is shepherding
    Extracted from Balloting:
    1. Tim Polk: Discuss [2008-09-11]: This is a discuss discuss, and I will definitely clear on the call.
      I wonder if the spec should recommend or even mandate support for Result Set Truncation (2.3.1).
    2. Magnus Westerlund: Comment [2008-09-10]:
      Section 3.2: I find it a bit confusing that one uses two different ABNFs in this document.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. (none)

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. WiMAX Forum/3GPP2 Proxy Mobile IPv4 (Informational)
    draft-leung-mip4-proxy-mode-09.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-09-02]: Three of the comments below are blocking (process issues and the EAP keying framework issue) in the sense that I would like to see them resolved before the IESG approves this spec according to RFC 3932 criteria. Given the small importance of those three issues, I am assuming that the authors are willing to do this.
      There is a fair number of other comments, which are not blocking but could affect interoperability, correctness of behaviour, or clarity of the specification. I am hoping that the authors are willing to revise the specification one more time in order to address these.
      Technical: Section 4.1.1 refers to an expired ID about the usage of GRE keying, in a manner that appears normative.
      Section 4.1.1 Step 6 claims that at this point the host has an address and DNS config. However, you did not mention earlier in the DHCP or IPCP cases that the DNS configs are exchanged;
      Section 4.3 explanation of IPsec usage is sketchy.
      Section 6.2 appears to propose an ICMP-based movement detection scheme which is likely inferior to the standard schemed defined in RFC 4436.
      Section 10 mentions that the relevant keys will be "derived by the EAP keying framework".
      There is no discussion of MTU issues in the document at all.
      There is no discussion of the requirements for the identification of a mobile node.
      There is no discussion of the implications of using Mobile IPv4 as defined and Proxy Mobile IPv4 for the same nodes.
      If you run this over PPP, bringing down the previous PPP connection and creating a new one would appear to cause the host to lose the IP address (and consequently, all ongoing sessions).
      The document does not at all discuss the role of the various identifiers (interface ID, device ID, subscriber ID, authentication NAI) and the access technology type.
      Section 3 claims IPv6 will work with PMIPv4 merely by the use of PMIPv4 and DSMIPv4 together. I find this hard to believe.
      Process issues: I think it would be useful to mention somewhere that there exists an IETF standard proxy mobile, RFC 5213.
      Section 3 says "In addition, the solution leverages standardized specification and highly available implementations." This could be mis-interpreted as PMIPv4 being a standard.
      Editorial: [8 nits]

    Telechat:

  2. Credential Protection Ciphersuites for Transport Layer Security (TLS) (Experimental)
    draft-hajjeh-tls-identity-protection-06.txt
    Token: Pasi Eronen
    Extracted from Balloting:
    1. Chris Newman: Comment [2008-09-08]: I concur that note #5 from RFC 3932 applies.

    Telechat:

  3. The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Experimental)
    draft-templin-seal-23.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. (none, but link wasn't there earlier this morning)

    Telechat:

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

    Telechat:

4.2.2 Proposed for Approval

  1. Operational Security Capabilities for IP Network Infrastructure (opsec)
    Token: Ron

    Telechat:

5. IAB News We can use

  1. Olaf: homing in on topic for technical plenary, evolution of the IP model, enumerate assumptions, are they still correct? Draft soon
    topics for IETF74, hoping to organize a bit in advance
    request from W3C: CT guidelines, OPES considerations drafted 2002, are they still appropriate, working on response saying not worried
    RFCed model discussion: last Friday I wrote what I thought was consensus, discussion more heated not, trying to keep momentum, make sure everyone is heard, need another iteration or two
    ISOC board vis Istar(?) trying to schedule Friday meeting, please reserve lunch on Friday

1229 EDT break

1235 EDT back

6. Management Issues

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

    Telechat:

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

    Telechat:

  3. Transfer of the MIB work from HUBMIB to the IEEE 802.3 (Dan Romascanu)

    Telechat:

  4. Large Interim Mtgs (Russ Housley)

    Telechat:

  5. Appeal from JFC (Russ Housley)

    Telechat:

  6. Question regarding expert review and independent submissions [IANA #189622] (Michelle Cotton)

    Telechat:

  7. IESG process change to action approval (Chris Newman)

    Telechat:

  8. EAP typecode expert (Jari)

    Telechat:

7. Agenda Working Group News

1404 Entered Executive Session

Valid HTML 4.01 Strict