IESG Narrative Minutes

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

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

Corrections from: Lisa, Russ

1 Administrivia

  1. Roll Call 1135 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. Referring to Multiple Resources in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-multiple-refer-03.txt
    Token: Cullen Jennings Note: Keith Drage is the document shepherd
    Extracted from Balloting
    1. Lisa Dusseault: Comment [2008-06-17]:
      In the Intro: example seems NOT enabled by protocol.
      Section 3: suggest mechanism in draft-ietf-sip-uri-list-message?
    2. Russ Housley: Discuss [2008-06-18]: did not see a reply to SecDir review

    Telechat:

  2. A general mechanism for RTP Header Extensions (Proposed Standard)
    draft-ietf-avt-rtp-hdrext-15.txt
    Token: Cullen Jennings Note: Tom Taylor is PROTO Shepherd
    Extracted from Balloting
    1. Pasi Eronen: Discuss [2008-06-18]: Section 5: What kind of resource should URI point to?
    2. Dan Romascanu: Comment [2008-06-18]: Should not this document be marked as updating RFC3550?
      Section 10 should be taken out from the final version of the document at publication.

    Telechat:

  3. Pseudowire (PW) Management Information Base (MIB) (Proposed Standard)
    draft-ietf-pwe3-pw-mib-14.txt
    Token: Mark Townsley
    Extracted from Balloting
    1. Russ Housley: Discuss [2008-06-17]: Abstract needs to be updated.
      Comment [2008-06-17]: Please delete from Introduction: "Comments should be made to PWE3 mailing list"
    2. Dan Romascanu: Comment [2008-06-16]: RFC2434 obsoleted by RFC5226.
      Section 6 should be renamed 'Structure of the MIB modules' and include information about the latest.
      suggest to document the enumerated values in the TCs in the IANA-PWE3-MIB

    Telechat:

  4. Two-Document ballot (Proposed Standard)
    draft-ietf-avt-rtp-jpeg2000-19.txt
    draft-ietf-avt-rtp-jpeg2000-beam-10.txt
    Token: Cullen Jennings Note: The document shepherd is Colin Perkins.
    Extracted from Balloting
    1. Russ Housley: Discuss [2008-06-17]: jpeg2000-19: justify need for random time stamp values
      jpeg2000-beam-10: Section 3.2: include the the algorithm used to generate the priority value.
      correct inconsistency between Sections 2.1 and 4.1
      Comment [2008-06-17]: jpeg2000-beam-10: Abstract could be more
      Security Considerations: "Care should be taken to prevent implementation bugs with potential security consequences.": Please provide more specific guidance or drop the sentence.

    Telechat:

  5. Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-uri-list-subscribe-02.txt
    Token: Cullen Jennings Note: Keith Drage is the document shepherd
    Extracted from Balloting
    1. (none)

    Telechat:

  6. Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-uri-list-conferencing-02.txt
    Token: Cullen Jennings
    Extracted from Balloting
    1. (none)

    Telechat:

  7. Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-uri-list-message-03.txt
    Token: Cullen Jennings Note: Keith Drage is the document shepherd
    Extracted from Balloting
    1. Lisa Dusseault: Discuss [2008-06-17]: possible attack with an unused 'recipient-list' body part
      in example figure 3, the Via header was removed. What is the correct behavior?
      Comment [2008-06-17]: Page 10, grammar nit: also I'd like a stronger term than "hint".
      The requirement related to CSeq should reference RFC3261?
      The VIA header field that the URI-list service adds should distinguish what it did from pure forwarding.

    Telechat:

  8. IANA Registration of Enumservices for Voice and Video Messaging (Proposed Standard)
    draft-ietf-enum-vmsg-02.txt
    Token: Jon Peterson
    Extracted from Balloting
    1. (none)

    Telechat:

  9. Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks (Proposed Standard)
    draft-ietf-pwe3-tdm-control-protocol-extensi-07.txt
    Token: Mark Townsley
    Extracted from Balloting
    1. Pasi Eronen: Comment [2008-06-18]: Section 3.6: bit diagram has type 0x0F, IANA Considerations text suggests value 0x11?
      Needs a normative reference to RFC 2119.

    Telechat:

  10. Using SCVP to Convey Long-term Evidence Records (Proposed Standard)
    draft-ietf-ltans-ers-scvp-06.txt
    Token: Tim Polk
    Extracted from Balloting
    1. Russ Housley: Discuss [2008-06-15]: suggest using LTANS-SCVP-EXTENSION instead of LTANS_SCVP_EXTENSION as a module name.

    Telechat:

  11. Basic Specification for IP Fast-Reroute: Loop-free Alternates (Proposed Standard)
    draft-ietf-rtgwg-ipfrr-spec-base-12.txt
    Token: David Ward
    Extracted from Balloting
    1. (none)

    Telechat:

  12. Sieve Email Filtering: Editheader Extension (Proposed Standard)
    draft-ietf-sieve-editheader-11.txt
    Token: Lisa Dusseault
    Extracted from Balloting
    1. Cullen Jennings: Comment [2008-06-18]: security section missing discussion of documents were "safe" or not
    2. Tim Polk: Discuss [2008-06-19]: security considerations should be supplemented with specific information about the IETF standards track mechanisms.
      At a minimum, should note that RFC 4871 specifies a set of "header fields [that] SHOULD be included in the signature"

    Telechat:

  13. AES-GCM Cipher Suites for TLS (Proposed Standard)
    draft-ietf-tls-rsa-aes-gcm-03.txt
    Token: Pasi Eronen
    Extracted from Balloting
    1. (none)

    Telechat:

2.1.2 Returning Items

  1. A Document Format for Requesting Consent (Proposed Standard)
    draft-ietf-sipping-consent-format-07.txt
    Token: Jon Peterson
    Extracted from Balloting
    1. Chris Newman: Discuss [2008-06-16]: does not comply with BCP 70 (RFC 3470) section 4.7.
    2. Tim Polk: Comment [2008-03-07]: In 3.1.3 Why not use MAY, MUST or SHOULD?
      Secdir review suggests that following the 4745 format more closely...

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters (BCP)
    draft-eastlake-ethernet-iana-considerations-07.txt
    Token: Dan Romascanu
    Extracted from Balloting
    1. Ron Bonica: Comment [2008-06-19]: support Mark's DISCUSS
    2. Lars Eggert: Discuss [2008-06-18]: Section 2.1.2, paragraph 9: we should require an RFC here.
      Comment [2008-06-18]: do you mean an IETF Standards Track RFC, or do you mean any standard published as an RFC
      Section 2.1.2, paragraph 14: Who is the expert? Do we need a management item to assign one?
    3. Mark Townsley: Discuss [2008-06-19]: Disagree with Lars about the use of an Internet Draft - numbers can be assigned before an RFC is approved when necessary. I am unsure about the policy asking IANA to archive an ID.
      For a very large allocation, perhaps we should give the expert the ability to "pass the buck" of responsibility to the IESG.

    Telechat:

  2. Sharing Transaction Fraud Data (Proposed Standard)
    (moved to section 3.2.1 during Agenda-bashing)
  3. SIV Authenticated Encryption using AES (Proposed Standard)
    draft-dharkins-siv-aes-04.txt
    Token: Tim Polk
    Extracted from Balloting
    1. Pasi Eronen: Discuss [2008-06-18]: So far, all crypto algorithms have been Informational RFCs
      Sections 6.1/6.2/6.3 say that P_MAX, A_MAX, N_MAX and C_MAX are "unlimited"; this isn't literally true
      Sections 6.1/6.2/6.3: shouldn't N_MIN be 0 instead of 1?
      Comment [2008-06-18]: Reference [DAE] should be informative
    2. Russ Housley: Discuss [2008-06-18]: DISCUSS DISCUSS: The IETF generally publishes cryptographic algorithms and modes as Informational RFCs. Why is this one appropriate for the standards track?
      Comment [2008-06-18]: It would be helpful to spell out SIV in the Abstract and Title.
    3. Cullen Jennings: Comment [2008-06-18]: Support Pasi discuss.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Four-Document ballot (Experimental)
    draft-ietf-rserpool-asap-20.txt
    draft-ietf-rserpool-enrp-20.txt
    draft-ietf-rserpool-common-param-17.txt
    draft-ietf-rserpool-policies-09.txt
    Token: Magnus Westerlund
    Extracted from Balloting
    1. Jari Arkko: Comment [2008-06-05]:
      • draft-ietf-rserpool-asap-20.txt: No-Obj
        Section 1: redundancy provided by SCTP is not "link-layer"
        Section 2.2.2: "deregistration is NOT allowed by proxy" how to check for this? If you can't test it, remove the statement.
        Section 2.2.5: How does the PU/PE know that a Home ENRP server has been added?
      • draft-ietf-rserpool-enrp-20.txt: No-Obj
        Section 3.2.1: "very remote chance (about 1 in about 4 billion)" by the birthday paradox the chances of such a conflict would be greater
      • draft-ietf-rserpool-common-param-17.txt: Yes
      • draft-ietf-rserpool-policies-09.txt: No-Obj (No comments.)
      • All the documents: I am not fond of "hard-outside-soft-inside" security model.

    Telechat:

  2. An Overview of Reliable Server Pooling Protocols (Informational)
    draft-ietf-rserpool-overview-06.txt
    Token: Magnus Westerlund Note: Doc Shepherd: Maureen Stillman
    Extracted from Balloting
    1. Jari Arkko: Comment [2008-06-04]: Section 4.2 model seems simplistic. not clear that default behaviour of sending unsent data is very useful.

    Telechat:

  3. Requirements for Management of Overload in the Session Initiation Protocol (Informational)
    draft-ietf-sipping-overload-reqs-04.txt
    Token: Jon Peterson
    Extracted from Balloting
    1. Russ Housley:Discuss [2008-06-17]: SecDir Review suggests that a discussion of denial-of-service attack mitigation should be added. some suggestions to implementors does seem prudent.

    Telechat:

  4. TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (Informational)
    draft-ietf-tls-ecc-new-mac-07.txt
    Token: Pasi Eronen
    Extracted from Balloting
    1. (none)

    Telechat:

3.1.2 Returning Items

  1. Threats Introduced by RSerPool and Requirements for Security in Response to Threats (Informational)
    draft-ietf-rserpool-threats-13.txt
    Token: Magnus Westerlund
    Extracted from Balloting
    1. Jari Arkko: Comment [2008-06-02]: Authentication is not the same as authorization. You need to specify what the authorization model is and how you implement it through protocols and formats. the -threats document should at least specify that the network administrators of a pool need to decide which nodes are authorized to participate in which roles.
      document was fairly hard to read, many sections differed from others in only minor ways.
    2. Chris Newman: Discuss [2008-06-04]: TLS is not an authentication mechanism. It is a framework that can be used to negotiate a security layer. TLS will not interoperate as an authentication service without a profile specifying how authentication is done for a particular application of TLS.
      In order to use TLS to provide authentication and authorization services, you need to describe a mandatory-to-implement authentication mechanism and procedures.
      Section 2.5.3: What is a "valid certificate"?
      Section 6.2.3: Using TLS for mutual authentication has been proven to be problematic
      Section 2.15.3: oddly worded and seems counter-productive

    Telechat:

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Sharing Transaction Fraud Data (Proposed Standard)
    (Moved here during Agenda-bashing)
    draft-mraihi-inch-thraud-06.txt
    Token: Tim Polk
    Extracted from Balloting
    1. Lisa Dusseault: Discuss [2008-06-18]: appears to be a cut-and-paste bug in the examples:
    2. Pasi Eronen: Discuss [2008-04-03]:
      • Appendix B example doesn't validate properly with the schema in Appendix A
      • S8.3: proposed hashing doesn't actually provide any security value.
      • Section 5.2.1, BankID: doesn't actually define what the element contains.
      • Section 5.2.2, AccountID: similar concerns
      • Section 5.7, AccountType: seems highly specific to the US banking system.
      • Section 4, Figure 2: doesn't quite match Figure 2 in RFC 5070
      • Section 5.4: the relationships of this class here and in the schema don't match.
      • Section 6: Figure 14 isn't in UML notation.
      • Appendix A: the schemaLocation seems to point some temporary web page
      • Section 4 does "Thraud Activity Report" intend to restrict multiple Incident elements?
      • Section 12, ISO 4217 should be a normative reference.
      • Section 9: Should this use IANA-allocated XML namespace and XML schema names?
      • For consistency with RFC 5070, several elements should use iodef:MLStringType
    3. Russ Housley: Discuss [2008-06-18]: DISCUSS DISCUSS: This document heading says that it is intended to become an Informational RFC. Yet, it is on the agenda to become a Proposed Standard. Why the difference?
    4. Tim Polk: Discuss [2008-06-19]: holding a discuss for IANA: doesn’t include templates for the registrations.
    5. Dan Romascanu: Discuss [2008-06-19]: discuss DISCUSS. whether this type of extensions to the IODEF model fall within the scope of the IETF. Do we really have the necessary expertise to review and approve a data model for transaction frauds? This looks to me at best an Informational document dealing with a specific 'vertical' application and certainly not a standards-track document.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. An Internet Transition Plan (Informational)
    draft-jcurran-v6transitionplan-03.txt
    Token: Ron Bonica
    Extracted from Balloting
    1. (none)

    Telechat:

  2. Comments on the Usefulness of Simple Best-Effort Traffic (Informational)
    draft-floyd-tsvwg-besteffort-04.txt
    Token: Lars Eggert Note: Suggested response: " 2. The IESG thinks that this work is related to IETF work done in TSVWG, but this does not prevent publishing."
    Extracted from Balloting
    1. (none)

    Telechat:

  3. Compressed Data within an Internet EDI Message (Informational)
    draft-ietf-ediint-compression-11.txt
    Token: Lisa Dusseault
    No Balloting link

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. Guidelines for Using the Privacy Mechanism for SIP (Informational)
    draft-munakata-sip-privacy-guideline-03.txt
    Token: Russ Housley
    (No Balloting link)

    Telechat:

1240 EDT break

1246 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. IP Security Maintenance and Extensions (ipsecme)
    Token: Pasi

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Pseudowire Emulation Edge to Edge (pwe3)
    Token: Mark

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. Loa: new 802.1 liaison; liaison shepherding process

6. Management Issues

  1. Shepherding NAT-PT (Mark Townsley)

    Telechat:

  2. Executive Session: Discussion of Appeal (Cullen Jennings)

    Telechat:

  3. RFC5056 Expert needed [IANA #125054] (Michelle Cotton)

    Telechat:

  4. Rechartering ???

    Telechat:

  5. Rechartering PCE?

    Telechat:

7. Agenda Working Group News

1355 EDT Went into executive session