IESG Narrative Minutes

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

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

Corrections from: Dan, 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. Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies (Proposed Standard)
    draft-ietf-sip-fork-loop-fix-07.txt
    Token: Cullen Jennings Note: Keith Drage is the PROTO shepherd
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-10-21]: It seems that proposed mechanisms don't work very well when SBCs (or other similar B2BUAs) are present -- does this mean the "doomsday scenario" described in Section 3 can still occur in deployments that have SBCs? (which means most real-world deployments, right?)
    2. Tim Polk: Discuss [2008-10-22]: I am not advocating any changes in the WG consensus mechanisms... That said, I believe the document does not adequately document the limitations of the mechanisms. Reading this document alone, I would believe that the set of mechanisms is a complete solution, and that further WG attention is not required.
      In particular, the Security Considerations section is devoted primarily to four rejected alternatives. What is really needed here is a description of the security considerations associated with the wg's consensus solution. Since overload is still a distinct possibility, the security considerations section should describe possible mitigation strategies as well.
      Comment [2008-10-22]: I was a little confused by the compliance language in section 4.2.1 and 4.2.2 of this specification. Specifically:
      In 4.2.1, the paragraph beginning with "Proxies required to perform loop-detection ..."
      In 4.2.2, the Loop Detection Check is defined based on the presence of the second part. This implies the statement above needs to be MUST.
      I may be missing something, but I would suggest the authors review 4.2.1 and 4.2.2 to ensure that the conformance requirements are consistent.

    Telechat:

  2. A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies. (Proposed Standard)
    draft-ietf-sipping-policy-package-05.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-10-23]: I would be much more comfortable with recommending approval of this document if draft-ietf-sip-session-policy-framework and draft-ietf-sipping-media-policy-dataset (two key normative references, both still in I-D Exists) would be already approved, or at least in IESG Evaluation. In particular, some of the security considerations seem to depend on those references -- e.g. what parts of the session description shouldn't be sent to the policy server (or viewed from another angle, what information the policy server can't use in formulating its policy decision) -- seem to depend on the references.
    2. Russ Housley: Discuss [2008-10-19]: The SecDir Review by Ran Canetti has not received a response. Ran points out that the content as well as the sever and user need to be authenticated. Ran also suggests that providing this authentication should not be optional.
    3. Tim Polk: Discuss [2008-10-22]: As noted in Ran Canetti's secdir review, the integrity of the content is equally important to the other security attributes identified in the Security Considerations. I agree with Ran's suggestion to mandate authentication of data and endpoints, and recommend confidentiality. However, implementing this suggestion will require clear guidance on how that is achieved where TLS is not employed...

    Telechat:

  3. Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE (Proposed Standard)
    draft-ietf-ccamp-rfc4420bis-03.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-10-23]: The only change in the spec is here:
      Length Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
      This is a good change, to align with the subobject format rules. However, the new text is no longer explicit about whether padding is or is not included in the length field. Can this be clarified?
    2. Tim Polk: Discuss [2008-10-22]: discuss - discuss.
      I would normally have expected new IANA assignments since the document changes the semantics of the length field. Implementations of 4420 and 4420bis will recognize the same Type number but will not interoperate based on differing interpretations. I recognize that 4420 was considered buggy, but are we confident that all implementers have already moved to the 4420bis semantics?

    Telechat:

  4. Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (Proposed Standard)
    draft-ietf-dime-mip6-integrated-10.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-10-23]: This is a good spec and I will vote Yes as soon as the following small issue is corrected:
      The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address and contains IPv6 or IPv6 address of the HA.
      Presumably IPv4 or IPv6 was meant here? In any case, the spec needs to be clear that both IPv4 or IPv6 address or both for the home agent can be delivered. In addition, the AVP specification(s) need to be clear that it is delivering *Mobile IPv6* home agent information.
    2. Pasi Eronen: Discuss [2008-10-23]: The relationship of this document and draft-ietf-mip6-radius is very unclear. In particular, the latter document defines RADIUS attributes for the same purpose as this document (same contents and semantics), and those attributes can be used in Diameter as-is (and the mip6 document says so). If this is indeed the case, why is this document needed at all?
    3. Chris Newman: Comment [2008-10-23]: I support the other ADs discuss positions.
    4. Tim Polk: Comment [2008-10-22]: In email Sept. 9, Jouni indicated his intention to add the following text to the security considerations, but it does not appear in the current RFC Editor note.
      The Diameter messages may be transported between the HA and the Diameter server via one or more AAA brokers or Diameter agents...
    5. Magnus Westerlund: Discuss [2008-10-23]:
      4.2.1. MIP6-Agent-Info
      There is formal notation that defines allowed behavior. However, there are no reference to the definition of this formal notation.

    Telechat:

  5. IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces (Proposed Standard)
    draft-ietf-sip-rph-new-namespaces-04.txt
    Token: Cullen Jennings Note: Keith Drage is proto shepherd
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-10-19]: The following 50 SIP namespaces are created by this document:
      dsn-000000 drsn-000010 rts-000020 crts-000000
      dsn-000001 drsn-000011 rts-000021 crts-000001
      dsn-000002 drsn-000012 rts-000022 crts-000002
      dsn-000003 drsn-000013 rts-000023 crts-000003
      dsn-000004 drsn-000014 rts-000024 crts-000004
      dsn-000005 drsn-000015 rts-000025 crts-000005
      dsn-000006 drsn-000016 rts-000026 crts-000006
      dsn-000007 drsn-000017 rts-000027 crts-000007
      dsn-000008 drsn-000018 rts-000028 crts-000008
      dsn-000009 drsn-000019 rts-000029 crts-000009
      The example used in the second half of section 2 makes use of dsn-000010, which is not defined in the list. Please use a defined namespace in this discussion.
    2. Tim Polk: Comment [2008-10-22]: I can accept the introductory statement:
      "DISA has a requirement to be able to assign different Resource-Priority namespaces to differing groups of differing sizes throughout their networks. Examples of this may be"
      but I must quibble with the second example:
      - some departments within the government (Homeland Security, Commerce, Treasury)
      Since when were Commerce and Treasury part of DISA's networks?

    Telechat:

  6. An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package (Proposed Standard)
    draft-ietf-sip-xcapevent-04.txt
    Token: Cullen Jennings Note: Dean WIllis is proto shepherd
    Extracted from Balloting:
    1. Lisa Dusseault: Comment [2008-10-22]: I have a bunch of editorial concerns with this document: requirements sentences with vague antecedents and other language issues that may even affect implementations and interoperability.
    2. Pasi Eronen: Discuss [2008-10-23]: It seems the ABNF in Section 4.3 doesn't actually match what it's supposed to match (concatenation has higher precedence than alternatives, so it needs parenthesis?).
      The examples in Appendix A contain some invalid XML
    3. Chris Newman: Comment [2008-10-23]: In addition to the ABNF problem Pasi noticed, the ABNF in this document depends on ABNF in RFC 3261, but that's not mentioned.

    Telechat:

  7. Textual Representation of AS Numbers (Proposed Standard)
    draft-ietf-idr-as-representation-01.txt
    Token: David Ward
    Extracted from Balloting:
    1. Chris Newman: Comment [2008-10-23]: this document doesn't really make sense without also understanding part of BCP 6. I recommend adding that as an informational reference.

    Telechat:

2.1.2 Returning Items

  1. Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services (Proposed Standard)
    draft-ietf-tsvwg-emergency-rsvp-09.txt
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Lisa Dusseault: Comment [2008-10-22]: I'm still confused by the architecture and by the discussions about the architecture. The security model is "walled garden" as far as I can tell, but the authors have argued that this work is within the IETF's remit as traffic will go on the open Internet. I also don't understand the inclusion of multicast merging rules.
    2. Pasi Eronen: Discuss [2008-10-23]: I largely agree with comments by Ron, Chris, David and Mark, but I'd like to discuss this on the telechat before deciding whether to go to Abstain or No Objection.
    3. Cullen Jennings: Comment [2008-10-22]: I am waiting for more information from Routing ADs on use of RAO in this constrained environment before deciding what position to take. I am happy with the updated document specifying the domain of applicability for the this.
    4. Chris Newman: Comment [2008-06-05]: I am not convinced either this proposal or any similar proposal can deploy in the real world. Furthermore, it would be harmful to the Internet to standardize a protocol that claims to provide prioritized traffic for emergency services when we don't believe it will deploy. I might be comfortable supporting an experiment in this area although I'm dubious such an experiment can actually succeed.
    5. Tim Polk: Comment [2008-06-05]: I support Ross's concerns regarding the router alerts and resulting security vulnerabilities. At a minimum, this aspect needs to be highlighted in the security considerations.
    6. Dan Romascanu: Discuss [2008-05-22]: The applicability of the extensions defined in this document is not described in terms consistent with other IETF work. From discussions with the authors it looks like this is intentional as the solution in the document describes an authority-to-any type of ETS communications currently not covered explicitly by ETS requirements documents as RFC3689/3690 or other emergency communication work in the IETF, but present in other documents in the industry or government requirements. It is however necessary that when we define a 'module' i.e. a piece of solution in an RFC we include references to what requirements or architecture work they are based upon. If the situation is that the requirements in 3689/3690 are at least partially timed out and this proposed RFC is answering a different set of requirements and fitting in different architecture agreed out of the IETF, I believe that those external references should be mentioned and referred to and not (only) the IETF documents as in the current list of references.
    7. Mark Townsley: Comment [2008-06-05]: I support the discuss comments about the use of router alert options.
    8. David Ward: Comment [2008-06-04]: Similar to my abstain on GIST docs, I am abstaining for reasons that Ross and Ron outlined.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (Experimental)
    draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-10-20]: Scott Brim raised two concerns in his Gen-ART Review.
      Section 2.1.1 says: "The contents of the UPSTREAM_FLOWSPEC Object MUST be constructed using a consistent format and procedures used to construct the FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]."
      This sentence is a little funky. Here are two possible changes:
      ... using a format and procedures consistent with those used to construct the FLOWSPEC ...
      ... using the same format and procedures used to construct the FLOWSPEC ...
      Sections 2.2.1 and 2.3.1 have the same issue.
    2. Magnus Westerlund: Discuss [2008-10-23]:
      I think this document should have been WG last called in TSVWG also before being progressed. The reason I bring this up is that objects like UPSTREAM_FLOWSPEC looks like it could have applicability for also classic RSVP usage. It needs to be clear if this has any or no applicability for Intserv usage etc. I therefore request an IETF last call to give my RSVP experts an opportunity to review this extension.
      Section 3: I am missing a reference to the formal language used to express the format.

    Telechat:

  2. A Hitchhiker's Guide to the Session Initiation Protocol (SIP) (Informational)
    draft-ietf-sip-hitchhikers-guide-05.txt
    Token: Cullen Jennings Note: Keith Drage is proto Shepherd
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-10-22]: Excellent work!
      One comment about Section 15 (security mechanisms): should it mention Digest AKA (RFC 3310/4169)?
      For someone trying to understand the SIP security better, other important pieces of information would be e.g. the "ipsec-3gpp" mechanism (defined in 33.203 but mentioned in RFC 3329), MIKEY, Kerberos/NTLM authentication for SIP (publicly documented, but not in IETF document AFAIK), and RFC 5090 (with many SIP-specific parts)...
    2. Russ Housley: Comment [2008-10-23]: The Gen-ART Review from Suresh Krishnan said: "I do have a nagging feeling that this document will be outdated by the time it will be published." It is possible to include some text that says something like snapshot of the relevant specifications and that updated versions of this document will be published periodically.
    3. Dan Romascanu: Comment [2008-10-23]:
      The document refers to a number of work-in-progress specifications... subject to change if and until they become RFCs.
      I think that it would be useful to provide more clarity to the last paragraph in the introduction that makes clear what the document is not.
      I think that the references sections would benefit from some kind of sorting.
      Section 11 should also include the SIP MIB (RFC 4780)
    4. Magnus Westerlund: Comment [2008-10-23]: Regarding RFC 3890, we know it is broken from a offer/answer perspective. Becuase TIAS values only makes fully sense in a sending direction and the reference to the handling of the other b= parameters makes it becomes a what I can receive. The text should maybe mention this.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') (Informational)
    draft-arkko-eap-aka-kdf-08.txt
    Token: Russ Housley
    Extracted from Balloting:
    1. Russ Housley: Discuss [2008-10-17]: The authors indicate that some last minute coordination with 3GPP is needed. I expect this coordination to take place between now and November 7th. If the coordination shows that no document changes are needed, then I will simply clear.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. Virtual Enterprise Traversal (VET) (Informational)
    draft-templin-autoconf-dhcp-18.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Tim Polk: Discuss [2008-10-09]: discuss discuss;
      I was a bit concerned by section 5 - post-configuration operation. This seems out of scope, and I am concerned that the content could unnecessarily constrain future wg activities.

    Telechat:

1244 EDT break

1249 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. Application-Layer Traffic Optimization (alto)
    Token: Lisa

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Behavior Engineering for Hindrance Avoidance (behave)
    Token: Magnus

    Telechat:

  2. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop)
    Token: Jari

    Telechat:

4.2.2 Proposed for Approval

  1. Simple Authentication and Security Layer (sasl)
    Token: Pasi

    Telechat:

5. IAB News We can use

  1. Amy: neither Olaf nor Loa here
    Russ: document on internal organization of RFCed: draft-iab-rfc-editor-model

6. Management Issues

7. Agenda Working Group News

1404 EDT Adjourned