IESG Narrative Minutes

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

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

Corrections from: Russ

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. A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link (Proposed Standard)
    draft-ietf-mpls-number-0-bw-te-lsps-11.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-08-26]:
      The document should reference [draft-ietf-isis-te-bis] instead of [RFC3784] (the latter would be a downref).
      Section 6: The reference to RFC 2470 ("Transmission of IPv6 Packets over Token Ring Networks") probably intends to point to RFC 5340 (which obsoletes RFC 2740).
      Section 6: The text should say security considerations for IS-IS are discussed in [draft-ietf-isis-rfc3567bis].
    2. Tim Polk: Discuss [2008-08-28]: In addition to the changes requested by Pasi, I believe an informative reference to draft-ietf-mpls-mpls-and-gmpls-security-framework would be appropriate in the security considerations section.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware (Proposed Standard)
    draft-cain-post-inch-phishingextns-05.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-08-27]: I support the DISCUSS from DNSOPS/Dan
    2. Lisa Dusseault: Discuss [2008-08-27]: Shouldn't there be an IANA registry for FraudType values?
      When ENUMs like FraudType are extended, will implementations break?
      The "company.com" domain in appendix C.1. Received Lure, actually exists, and is registered to "Company.com, Inc.". The domain "nospa.us" is not registered but could be. I'm particularly concerned about the implication that company.com is a phisher.
      COMMENTS: The diagram in figure 2.1 has a link from "Collection point" back to "Fraudster". I can't make sense of it.
    3. Lars Eggert: Discuss [2008-08-11]: DISCUSS-DISCUSS: "Anti-Phishing Working Group" makes it sound like this is an IETF activity when it's not.
      Comment [2008-08-11]: Section 4.4., paragraph 1: Is the text in brackets an RFC Editor Note, i.e., should the RFC Editor change 0.04 to 1.0?
    4. Pasi Eronen: Discuss [2008-08-28]: currently it looks very much like work-in-progress, and clearly needs more work. I have quite large number of comments, and I expect that more than document revision will be needed.
      [lots of major issues elided]
      [a few dozen Minor clarifications elided]
    5. Cullen Jennings: Comment [2008-08-27]: I'm not sure that voip is the fraud type you want in section 4.5.
    6. Chris Newman: Comment [2008-08-28]: I support Lisa's discuss.
      Some problems with XML schema are explained in BCP 70 section 4.7.
    7. Dan Romascanu: Discuss [2008-08-26]: partially based on the DNS Directorate review by Peter Koch.
      1. DomainData element: How is usage defined here? If "www.example.com" was "used", would "www.example.com" or just "example.com" appear in the report?
      2. [CRISP] reference is broken - the name of the RFC is different, the protocol is IRIS and not CRISP.
      3. role-ext attribute: Why have the attribute values been chosen to differ from those defined in IRIS-DREG?
      4. 4.9.7.1.1. Name element: shouldn't the document then at least have a reference to such Key Names' syntax?
      5. 4.17.2.2. ARFText: This seems to suggest a normative reference to the "Abuse Reporting Format", but the [ARF] reference is informative only
      Comment [2008-08-26]:
      1. 3.3. Correctness of Fraud Activity Reports: should be renamed "Syntactical Correctness ..."
      2. Section 4.4: This should be marked as a note to RFC Editor
      3. There are several ENUM attributes that place 'other' or 'unknown' values at the end of the enum list. The better practice is to place such special values at the begining
      4. 4.5. FraudType attribute 5. dnsspoof: DNS spoofing is usually to involve forged DNS responses, not manipulating the resolution path. It could be argued that in the case described here, DNS doesn't even get used.
      5. 4.9.2. DomainData element: It is unclear what "domain used to source the lure" means. Is it the header or envelope From address of an email?
      6. 4.9.2.6.1. owner element: "Superior node" is either a wrong description or an outright misunderstanding of what a "DNS owner name" means.
      7. 4.9.2.6.3. class element: This seems to be in conflict with the schema defined later, which makes this mandatory.
      8. 4.9.2.7.1. SameDomainContact: This tacitly assumes a "thin registry" model; s/registrar/registrar or registry/
      9. 4.9.3. SystemStatus attribute: Domains are elements in a name space, not acting parties.
      10. 4.9.4. DomainStatus attribute: See the other comment about the [CRISP] reference and note that the document is no longer an Internet-Draft, but an RFC
      11. 4.17.1. EmailCount: s/enumerates/contains/
      12. I support Lars's DISCUSS about the need to clarify that the Anti-Phishing Working Group is not an IETF WG.
    8. Mark Townsley: Comment [2008-08-28]: Support Dan's comment about the DNS review comments not being addressed.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Why Authentication Data suboption is needed for MIP6 (Informational)
    draft-ietf-mip6-whyauthdataoption-06.txt
    Token: Jari Arkko Note: No document shepherd -- old MIP6 document
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-08-26]: I think the document's discussion of pros and cons of authentication option and IPsec is a bit too 3GPP2-centric... (proposing text for Section 7)...
      Minor clarifications/nits:
      - Section 6: It would be useful to have some pointers here (to 3GPP2 specs where the details of these procedures are specified).
      - Section 10: The sentence "Mobile IPv6 has been standardized only recently" was accurate when version -00 of this draft was published in 2005, but it isn't that recent now.
    2. Tim Polk: Comment [2008-08-28]: I wish this document had evolved into a more even treatment of the applicability of RFC 4285 and RFC 4877. Documenting the process more generically, then using 3gpp as an example would have made the document easier for future system architects to apply the information when architecting their own solutions. I think implementing Pasi's proposals or something similar would certainly be helpful.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational)
    draft-cam-winget-eap-fast-provisioning-09.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-08-28]: I think the spec is in reasonable shape but needs one more revision to clarify a number of details. I also agree with Pasi's issues, and they should be fixed.
      additional things that I found:
      "When using this mode, an inner, phase 2, EAP method SHOULD be used to provide authentication and man-in-the-middle detection as described in Section 6. If an anonymous tunnel is used then the peer and server MUST negotiate and successfully complete an EAP method supporting mutual authentication and key derivation."
      It seems that the SHOULD and the MUST in conflict.
      Section 3.2 says "Once a protected tunnel is established, the peer and server MAY wish to execute additional authentication and perform checks on the integrity of the TLS tunnel."
      4 - A-ID... 5 - I-ID...It is unclear what formats these must be in
    2. Lars Eggert: Comment [2008-08-11]: The document writeup says "... The purpose of this document is to publish existing behavior." I wonder if this should be explicitly called out in the abstract and/or introduction?
    3. Pasi Eronen: Discuss [2008-08-28]:
      Section 3.1.1: If the certificate chain is not validated, it's not obvious how it's different from not authenticating the server at all.
      Section 6.1.2: The part "or the peer lacks.." suggests that you could do Server-Unauthenticated mode with RSA ciphersuites and just omit verifying the certificate. In most places that use TLS, that would be indeed fine -- but not here.
      Section 4.1.3: How is the User Authorization PAC sent to the server?
      Section 6.4: If this section intends to profile TLS by saying that the generator MUST be 2, and clients are required only to support the groups in RFC3526, it needs to be clearer.
      Section 6.4: I'm not sure everyone would agree that computing new random groups actually improves security
      Section 3.5 provides two different ways to run another EAP-FAST exchange. Are both of these mandatory to support?
      [Other clarifications elided]
    4. Russ Housley: Comment [2008-08-22]: Please consider two comments from Gen-ART Review:
      In S4.1.{2,3}, there is a term "PAC opaque". I think you mean "PAC-Opaque", the opaque data that was defined in S4.1.1.
      In S6.3, first paragraph: should the "should" on line 3 be normative? the "MAY" seven lines down is normative.
    5. Chris Newman: Discuss [2008-08-27]: Who is proposed as the designated expert for the registry?
      Comment [2008-08-27]: it's helpful to give a title for the registry as this is the only way readers of the document can find the IANA registry.
    6. Mark Townsley: Comment [2008-08-28]: General area seems odd for this document. Tracker mistake?

    Telechat:

  2. Diameter ITU-T Rw Policy Enforcement Interface Application (Informational)
    draft-sun-dime-itu-t-rw-01.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Cullen Jennings: Comment [2008-08-27]: The diameter RFC requires IETF consensus for command codes extensions. This draft simply circumvents that process.
    2. Chris Newman: Discuss [2008-08-28]: Based on GEN-ART review responses, it appears the statement in the DIAMETER base spec: "Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting." is spurious and not being followed.
    3. Mark Townsley: Discuss [2008-08-28]: From the text... It sounds to me like like all these extensions are falling under a vendor-id protocol space. Why does this require IANA allocation at all then? And, by extension, this RFC?

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. SNMP Traffic Measurements and Trace Exchange Formats (Informational)
    draft-irtf-nmrg-snmp-measure-05.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-08-27]: It would be great if the authors would be able to fix the scheme errors noted in Pasi's review.
      I have to wonder whether the use of encryption would be compatible with being able to use the packet traces. Do SNMP security mechanisms encrypt entire packets, hiding OIDs and operations, or just the actual object values?
    2. Pasi Eronen: Comment [2008-08-26]: The example XML document doesn't actually validate with the schema
    3. Chris Newman: Comment [2008-08-28]: Were this an IETF document I would want to discuss how it addresses BCP 70 section 4.7. Specifically: "... the extensibility design should be clear. What happens if the data is not valid?:
    4. Tim Polk: Comment [2008-08-28]:
      References in sections 2, 2.1, 2.2, and the first paragraph of 2.3 inconsistent with References section
      I thought the document's guidance on storing raw traces a bit confusing.

    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. Operational Security Capabilities for IP Network Infrastructure (opsec)
    Token: Ron

    Telechat:

4.2.2 Proposed for Approval

  1. Sieve Mail Filtering Language (sieve)
    Token: Lisa

    Telechat:

  2. Layer 2 Virtual Private Networks (l2vpn)
    Token: Mark

    Telechat:

1252 EDT break

1257 EDT back

5. IAB News We can use

  1. Loa: discussion yesterday on evolution of IP model; slides soon; team for future IAB plenaries (73/74 planning); no response to my note asking about experimental RFC -- downgrading from what they were intended to be
    from my point of view, Experimental should mean a defined experiment
  2. Russ: agree we should discuss: do we need joint session?
  3. Loa: not an IAB thing
  4. Loa: Ross action point PCAP?
  5. Ross: interas requirements? LastCall ended July 31
  6. Russ: would like you to formally announce your statement of LastCall results
  7. Loa: would prefer that sort of document be appropriate for normative referencing
  8. Russ: maybe we should change process so we lastcall requirements documents
  9. Loa: not in a hurry, not specific to this document; requirements documents tending towards normative

6. Management Issues

  1. Input on notation for 4-byte (32-bit) AS Numbers (Michelle Cotton)

    Telechat:

  2. IESG Requirements for NomCom (UPDATED) (Russ Housley)

    Telechat:

  3. Friday Meetings in Minneapolis (Russ Housley)

    Telechat:

  4. Registration procedures for arp-parameters (hardware types) [IANA #183428] (Michelle Cotton)

    Telechat:

  5. Revised guidance for interim meetings (UPDATED) (Russ Housley)

    Telechat:

  6. Executive Session: First draft of appeal response (Lisa Dusseault)

    Telechat:

7. Agenda Working Group News

1427 EDT Entered executive session