IESG Narrative Minutes

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

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

Corrections from: Russ, Dan, Tim, 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. Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices (Proposed Standard)
    draft-ietf-ipcdn-pktc-eventmess-13.txt
    Token: Dan Romascanu Note: Richard Woundy [Richard_Woundy@cable.comcast.com] is the PROTO shepherd of this document.
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-07-13]: The default for pktcEventSyslogTransport is syslog transport over TLS, but port 514 is only reserved for syslog over UDP. 514 should be changed to the port number allocated by IANA for draft-ietf-syslog-transport-tls, which is currently with the RFC Editor.
      Comment [2008-07-11]: Section 6., paragraph 32: Please define what exactly is meant by non-routable addresses.
    2. Pasi Eronen: Discuss [2008-07-17]: Spelling of SyslogSeverityMask labels should be aligned with SyslogSeverity labels. Also affects DESCRIPTION text of pktcEventClassSeverity and pktcEventReporting.
    3. Cullen Jennings: Comment [2008-07-16]: This was one of the most easy to understand MIBs I have read. Thanks.

    Telechat:

  2. A Two-way Active Measurement Protocol (TWAMP)
    (deleted from agenda by mistake)
    draft-ietf-ippm-twamp-08.txt
    Token: Lars Eggert Note: Document Shepherd: Henk Uijterwaal (henk@ripe.net)
    Extracted from Balloting:
    1. Magnus Westerlund: Comment [2008-07-15]: Section 4.2.1: "with the implication that the later two modes will not fit in a single ATM cell"
      Is this comment at all relevant as there will be an IP and UDP header on the packet also, making the smallest packet size become 28+41? Or is the intention to allow the format to be used with other encapsulations than IP/UDP? Then I would expect a clearer description of this fact and recommendation on what is necessary for that usage.

    Telechat:

  3. Carrying Location Objects in RADIUS and Diameter (Proposed Standard)
    draft-ietf-geopriv-radius-lo-19.txt
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-07-11]:
      Section 4.7., paragraph 8: why is it useful to allow an out-of-band agreement to override protocol semantics?
      Section 8.1., paragraph 6: It is up to the IESG to appoint designated experts
      Section 11.2., paragraph 5: should this be a normative ref?
      Comment [2008-07-11]:
      Section 4.1., paragraph 17: Suggest to move this example down to the description of the REALM namespace
      Section 4.2., paragraph 2: Why is this a SHOULD and not a MUST?
      Section 4.4., paragraph 19: The APP ADs should look at this.
      Section 4.4., paragraph 21: Are there any protocol or encoding mechanisms in place to prevent this sharing, or do we simply trust the other end to conform to our wishes? (Same issue applies to "retention-expires".)
      Section 4.6., paragraph 1: Why is this a SHOULD NOT? When is it permissible to challenge?
      Section 6., paragraph 2: (don't abbreviate RFC2119 terms)
      Section 8.1., paragraph 3: The ADs are at ops-ads@ietf.org.
      Section 8.2., paragraph 6: It's usually much safer to deprecate registry entries or to make them historic, compared to simply removing them.
      Section 9., paragraph 1: It's a bit unusual to thank a co-author, but hey :-)
    2. Russ Housley: Discuss [2008-07-12]: There was a dialogue between Glen Zorn and Bernard Aboba during IETF Last Call. I expected the dialogue to result in changes to the document... Yet, the document has not been updated and there are not notes to the RFC Editor to resolve this issue.
    3. Tim Polk: Discuss [2008-07-17]: This is a Discuss Discuss. I will either move to No Object or revise to make this actionable after the call.
      This specification permits multiple Location-Information and Location-Data attribute pairs. Are there issues with respect to inconsistency between the civic and geospatial locations?
      Are there good reasons to request (or supply) both locations? I could imagine scenarios where both locations are known with sighting times, or wildly different granularities and this could result in conflicting authorization decisions or billing results. Should the spec provide any guidance?
    4. Dan Romascanu: Discuss [2008-07-17]: The content for this DISCUSS includes comments from AAA-Doctor David Nelson
      based in IETF Last Call comments that seem not to have been resolved: This document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute. Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.
      This issue was discussed with the authors and in comments upon various early versions of the draft on the RADEXT WG mailing list (some CC'ed to the GEOPRIV WG mailing list).
      In fairness, some improvement in attribute design has occurred with successive versions. Still, there are several attributes that define sub-fields within them, contrary to the guidance of the RADIUS Design Guidelines. The most recent discussion of these issues occurred during IETF Last Call on the draft.
      There are good reasons for the guidelines. One of the design principles is to allow RADIUS servers to "enroll" new attributes by means of additions of a data dictionary. A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets. In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information.
      Another RADIUS design / documentation principle is that one does not define the functionality of a *service* in a RADIUS document. If the GEOPRIV Location Information attributes require the complex, structured attribute values, as present in the current draft, then use of RADIUS Extended Attributes, which provide a formalized mechanism for structuring and grouping, is the recommended design practice.
      It looks that the least that is required of this document is to point out the inconsistencies with the RADIUS Design Guidelines, and warn readers of the document not to consider it a precedent for new design work, but rather steer them to the RADIUS Design Guidelines document for design guidance.
      Comment [2008-07-17]: In the table in Section 8.1 please change s/ops-chairs@ietf.org/ops-ads@ietf.org/

    Telechat:

  4. Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists (Proposed Standard)
    draft-ietf-sipping-capacity-attribute-06.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-07-11]: Miguel's affiliation and email address have recently changed.

    Telechat:

  5. Ethernet Pseudowire (PW) Management Information Base (MIB) (Proposed Standard)
    draft-ietf-pwe3-enet-mib-13.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-07-12]: Please remove "Comments should be made directly to the PWE3 mailing list"
    2. Dan Romascanu: Comment [2008-07-16]: [typos, mostly]
      --- Conformance description... Normally (as listed in RFC4181) we order then with Compliances first and then Groups.
      In the Security Considerations section: - the security threat resulting from intentional or unintentional mis-configuration of the obects in the pwEnetTable should be explicitly stated

    Telechat:

  6. Pseudowire (PW) over MPLS PSN Management Information Base (MIB) (Proposed Standard)
    draft-ietf-pwe3-pw-mpls-mib-14.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-07-01]: Editorial nits from Stephen Hanna's SecDir review:
    2. Russ Housley: Comment [2008-07-12]: Please remove "Comments should be made directly to the PWE3 mailing list"; Please expand "PSN" the first time it is used.
    3. Dan Romascanu: Comment [2008-07-16]: The comments are partiallybased on the MIB Doctor review performed by Orly Niklass
      In the Security Considerations section: - the security threat resulting from intentional or unintentional mis-configuration of the obects in the pwEnetTable should be explicitly stated
      --- Conformance description... Normally (as listed in RFC4181) we order then with Compliances first and then Groups.

    Telechat:

  7. OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (Proposed Standard)
    draft-ietf-ccamp-ospf-interas-te-extension-05.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-07-16]: Based on the Gen-ART Review by Joel Halpern: The last sentence of the Abstract is not clear.
      Please add a note to the introductory material in section 3 that provides the rationale for this extension
    2. Tim Polk: Discuss [2008-07-17]: The last sentence in the security considerations merits expansion: "Note, further, that if BGP is used to exchange TE information as described in Section 4.1, the inter-AS BGP session will need to be fully secured." Are we talking about authenticating the origin of the information (which corresponds to the scope of 4.1) or is confidentiality required as well?
    3. David Ward: Discuss [2008-07-16]:
      Section 2.2 needs proper referencing of path msg, ero, etc
      section 3: runon sentence:
      3.x: It is infinitely easier to understand the bit placement and definition if the LSAs are actually diagrammed.
      3.2.1 Is this expected to be a common practice: "Note that it is possible to include the IPv6-Remote-ASBR-ID sub-TLV in the Link TLV of the Inter-AS-TE-v2 LSA, and to include the IPv4-Remote-ASBR-ID sub-TLV in the Link TLV of the Inter-AS-TE-v3 LSA because the sub-TLVs refer to ASBRs that are in a different addressing scope (that is, a different AS) from that where the OSPF LSA is used." Seems like a great way to fubar yourself.
      3.3.1 What happens during a transition from 2 byte to 4 byte AS? can this be done seemlessly by refloding the LSAs? What about a transition of ASN?
      Section 5: Should there be a MUST check if this is the case: "It is worth noting that in the scenario we are considering a Border Gateway Protocol (BGP) peering may exist between the two ASBRs and this could be used to detect inconsistencies in configuration. For example, if a different remote AS number is received in a BGP OPEN [BGP] from that locally configured into OSPF-TE, as we describe here, then something is amiss. Note, further, that if BGP is used to exchange TE information as described in Section 4.1, the inter-AS BGP session will need to be fully secured." vs "something is amiss?"
      General question: -- If the link to another AS is on a bcast media shared w/ connectivity to other AS', what should TE values should be flooded? What happens if a peering link is flapping?

    Telechat:

  8. Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions (Proposed Standard)
    draft-ietf-pce-pcep-xro-05.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Tim Polk: Comment [2008-07-17]: In security considerations section, the phrase "increases the risk" begs the question "what risk?" After reviewing pce-pcep-12, I would hazard a guess that the increases in risk are limited to PCEP Privacy (section 10.2 of pce-pcep) and possibly the DOS attacks described under Request Input Shaping/Policing (section 10.3.2 of pce-pcep). If my analysis is correct, it would be nice to expand on "risk" and explicitly identify the concerns. If other risks are impacted by this specification, that would be very helpful as well.
    2. Dan Romascanu: Comment [2008-07-15]: The Manageability Consideration section includes a reference to a PCEP MIB document... Actually right now there is no PCEP MIB in works. If a PCEP MIB will be the object of future work the text needs to be changed accordingly to avoid confusion.
    3. David Ward: Discuss [2008-07-16]: Need 4 byte ASN support.
      I'd beef up the security section w/ more from 3.1.1 but, I get both sections as is.

    Telechat:

2.1.2 Returning Items

  1. GIST: General Internet Signalling Transport (Proposed Standard)
    draft-ietf-nsis-ntlp-16.txt
    Token: Magnus Westerlund WG Shepherd: Martin Stimerling. Note: Please re-evaluate your abstains
    Extracted from Balloting:
    1. Ross Callon: Comment [2007-04-03]: I changed my vote to "abstain" because I still feel that this should be "experimental"... To me this appears to have very substantial implications on routers, hosts, and other devices as well.
    2. Brian Carpenter: Comment [2007-03-16]: [Yes, these Comments really _are_ that old!]
      I'm very doubtful about the real deployability of GIST; these extracts say why:
      1.1. Restrictions on Scope: the path taken by a single flow in the network may not be well defined. If this is the case, GIST cannot route signaling meaningfully.
      2007-03-16: This text has disappeared in version -11, but elsewhere in the document I find: "This specification does not define mechanisms for GIST to manage multiple parallel routes or an unstable route."
      Legacy NATs: GIST messages will generally pass through NATs, but unless the NAT is GIST-aware, any addressing data carried in the payload will not be handled correctly.
      2007-03-16: This text has disappeared in version -11, and section 7.2.1 has been added. That is good, but it does document that in some NAT scenarios, GIST will simply fail.
      Is it certain that flow splitting can't be handled by an extension to the route change mechanism?
    3. Bill Fenner: Comment [2006-09-27]: No Further Objection. My concerns are adequately covered by several other DISCUSSes.
    4. Cullen Jennings: Comment [2008-04-03]: Both the routing AD have abstained on this because they do not believe it is appropriate for internet routing. I have heard their arguments, believe they are sound, and support their position.
    5. Chris Newman: Comment [2007-04-12]: This document is so long and complex that I consider it highly unlikely it will deploy. As a result I am not concerned it will cause harm to the infrastructure. Because the WG delivered on its charter item I will vote no objection. Were this an individual submission, I would probably abstain.
    6. Tim Polk: Comment [2008-03-27]: I have a vaguely uneasy feeling on this document... the complexity seems to be substantial. I am joining the ABSTAINs for now, I could change my position if convinced this is both implementable and not dangerous to the Internet. If I do change my position, I would move to DISCUSS to address the following issue.
      Support for TLS is required, but different modes may be selected (e.g., different ciphersuites and authentication mechanisms). These changes significantly impact the security provided (and as a result, the degree to which the requirements in 4081 are met.) The security considerations section should elaborate on the impact of server-only vs. mutually authenticated TLS, as well as alternative authentication procedures, with respect to the various requirements.

    Telechat:

    (later in Telechat):

2.2 Individual Submissions

2.2.1 New Items

  1. Ogg Media Types (Proposed Standard)
    draft-goncalves-rfc3534bis-07.txt
    Token: Magnus Westerlund Note: Intended for AD sponsoring
    Extracted from Balloting:
    1. (none)

    Telechat:

  2. Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (Proposed Standard)
    draft-black-ipsec-ikev2-aead-modes-01.txt
    Token: Tim Polk Note: pseudo Last Call on ipsec@ietf.org
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-07-17]:
      Section 12: the numeric identifiers should be "TBD-BY-IANA"
      Section 1, "The current version of ESP is version 2, ESPv2 [RFC4303]": its version 3 (v1 was RFC 1827; and the draft that became RFC4303 was also named draft-ietf-ipsec-esp-v3).

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. A Framework for Packet Selection and Reporting (Informational)
    draft-ietf-psamp-framework-13.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. (none)

    Telechat:

  2. TCP's Reaction to Soft Errors (Informational)
    draft-ietf-tcpm-tcp-soft-errors-08.txt
    Token: Lars Eggert
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-07-17]: This is a welcome document, and a very useful spec to publish. I have a few issues with the document, however.
      First, I was unable to find any evidence of review from the 6MAN or V6OPS communities. Has there been such review, and if not, can we ensure it happens now?
      Section 2.1 says: When receiving an ICMP error message that indicates a hard error condition, TCP will simply abort the corresponding connection, regardless of the connection state.
      Question. ICMP errors can be due to denial-of-service
      Section 3.2 [soft errors]: Clarity. This is somewhat misleading. When the node has no default routers it also has no prefixes, no global addresses and it will not even try to use IPv6 towards other global addresses. That is not a soft error situation as described by this document.
    2. Russ Housley: Discuss [2008-07-16]: I have not seen a response to the comments in the SecDir Review

    Telechat:

  3. Analysis of Inter-domain Label Switched Path (LSP) Recovery (Informational)
    draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. (none)

    Telechat:

  4. Inter-AS Requirements for the Path Computation Element Communication Protocol (PCEP) (Informational)
    draft-ietf-pce-interas-pcecp-reqs-06.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. (none)

    Telechat:

    (later in Telechat):

  5. AAA Goals for Mobile IPv6 (Informational)
    draft-ietf-mext-aaa-ha-goals-01.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Russ Housley: Discuss [2008-07-12]: Eric Gray posted a Gen-ART Review of during IETF Last Call, but it has not received a response.
    2. Tim Polk: Comment [2008-07-17]: In section 4.2, Integrated Scenario, the acronym AAAH is introduced without any explanation. I finally found it in RFC 4285. That was painful, and could have been avoided by either noting that some terms are extracted from [5] in section 2, Terminology, or expanding it on first use.
      Nits: Section 4.1, 4.2

    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. Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment (Informational)
    draft-sanjib-private-vlan-09.txt
    Token: Mark Townsley Note: This is an independent submission, going on telechat for RFC3932 check.
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-07-17]: I support Lars's Discuss.
      In addition, in my quick review I came to the conclusion that its hard to classify this as anything else than RFC 3932 response 1. No protocol is extended, this is merely a way to use bridges and set up subnets.
      Having said that, I have real concerns about the document. For instance, the document does not contain the words "multicast" or "IPv6" and explain what its arrangement does for those. The document does not explain what, if anything, breaks when you do this. I suspect something does. Also, I would be very interested in understanding the role of this document vs. deployment models in DSL. If this is something that DSL Forum would be relying on, for instance, we should rather review this in the IETF so that some of the above issues could be checked. Or is this purely a vendor spec?
    2. Lars Eggert: Discuss [2008-07-11]: Mark, which RFC3932 response are you proposing for this document? (Putting this in as a discuss so it doesn't slip through.)

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. ECC Brainpool Standard Curves and Curve Generation (Informational)
    draft-lochter-pkix-brainpool-ecc-01.txt
    Token: Tim Polk
    (No Balloting link)

    Telechat:

1257 EDT break Cullen: don't expect I'll be back, I've no problem with Management items.

130 EDT back

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. Sieve Mail Filtering Language (sieve)
    Token: Lisa

    Telechat:

4.2.2 Proposed for Approval

  1. Common Control and Measurement Plane (ccamp)
    Token: Ross

    Telechat:

  2. Multiprotocol Label Switching (mpls)
    Token: Ross

    Telechat:

  3. Network-based Localized Mobility Management (netlmm)
    Token: Jari

    Telechat:

  4. Benchmarking Methodology (bmwg)
    Token: Ron

    Telechat:

5. IAB News We can use

  1. Loa: wasn't at yesterday's meeting.
  2. Russ: Alcatel speaker may not be able to reschedule Wed vs. Thurs
  3. Mark: IAB working on NomCom stuff

6. Management Issues

  1. Friday Meetings in Minneapolis (Russ Housley)

    Telechat:

  2. [IANA #177572] (Michelle Cotton)

    Telechat:

  3. Approval of registration procedures for bgp-well-known-communities [IANA #178310] (Michelle Cotton)

    Telechat:

  4. Move L3VPN WG from INT area to RTG area (Mark Townsley)

    Telechat:

  5. Statement on Errata (Cullen Jennings)

    Telechat:

  6. Proposed update to ID-Checklist (Russ Housley)

    Telechat:

7. Agenda Working Group News

1351 EDT Adjourned