IESG Narrative Minutes

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

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

Corrections from: Russ, Magnus

1 Administrivia

  1. Roll Call 1136 EDT Amy: really bad echo... trying to resolve... 1137
  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. Transmission Time offsets in RTP streams (Proposed Standard)
    draft-ietf-avt-rtp-toffset-07.txt
    Token: Cullen Jennings Note: Tom Taylor is the PROTO Shepherd
    Extracted from Balloting:
    1. Tim Polk: Comment [2008-10-07]:
      recommend adding a sentence pointing to RFC 3550 for the core security considerations.
      FYI, [hdrext] is now RFC 5285. Perhaps that should be added to the RFC Editor Note.
    2. Magnus Westerlund: Comment [2008-10-08]: the recommended RTCP packet type 195 is not from the first choice range established by the approval of draft-ietf-rtp-and-rtcp-mux some time ago. The value is from the second range and not a problematic one.

    Telechat:

  2. Example calls flows of race conditions in the Session Initiation Protocol (SIP) (BCP)
    draft-ietf-sipping-race-examples-06.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. (no balloting link)

    Telechat:

  3. ForCES Forwarding Element Model (Proposed Standard)
    draft-ietf-forces-model-16.txt
    Token: Ross Callon
    Extracted from Balloting:
    1. Tim Polk: Comment [2008-10-08]: (The security considerations includes a reference that is inconsistent with the surrounding text. The text refers to RFC 3746, which is reference [5] but [2] is the reference that is included in the text.)
    2. Dan Romascanu: Comment [2008-09-24]: does not include the standard phrase about keywords required by RFC 2119.The replacement phrase in the introduction does not mention for example 'MUST NOT' although there are a number of instances of 'MUST NOT' in the text.

    Telechat:

  4. CAPWAP Protocol Specification (Proposed Standard)
    draft-ietf-capwap-protocol-specification-13.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-09-24]:
      Section 3.3., paragraph 3: http://www.iana.org/assignments/multicast-addresses does not list a well-known IPv4 multicast address reserved for CAPWAP, and Section 15.1 only requests allocation of a new IPv6 multicast address. Which well-known multicast address should be used for CAPWAP with IPv4?
      Comment [2008-09-23]: Agree with the comments of the gen-art reviewer.
      Section 3.3., paragraph 5: does that mean that the AC needs to always listen for Discovery Requests by all three means?
      Section 4.5.2., paragraph 3: It'd be good to somewhere in Section 4.5.2 mention that this DSCP designates the EF PHB and refer to RFC2598.
      Section 4.6.9., paragraph 1: This is the first time load balancing is mentioned in this document, and there are only two other mentions, neither of which explains how load balancing is to be performed?
      Section 4.6.11., paragraph 1: This is not a reliable technique for NAT detection, because it fails when address spaces are overlapping. (Same for Section 4.6.12.)
      Section 4.6.38., paragraph 0: I'd add a statement in this section along the lines of: "The exchange of vendor specific data between the MUST NOT modify the behavior of the base CAPWAP protocol and state machine."
      Section 11., paragraph 2: The UDP source ports will be different for the two connection requests, which could be used to distinguish them.
      Section 11., paragraph 4: Because all communication originates at the WTP and is addressed to the AC, communication when the AC is behind a NAT will simply fail.
      Section 15.11., paragraph 0: Why not simply reuse the Internet Protocol Numbers registry instead of creating a new one?
    2. Pasi Eronen: Comment [2008-09-25]: In Section 4.5.3, both instances of "modulo 32" should be "modulo 256".
      In Section 4.6.36 (Session ID message element), the length should be 16 octets instead of 32.
      In Section 15.3, the range to be managed by IANA is not 32 bits, but only 8 (i.e. the unassigned values are 27-255, not 27-4294967295).
    3. Russ Housley: Comment [2008-09-22]: Suresh Krishnan did a Gen-ART Review of -11 on 12 Aug 2008, and I have not seen a response to this review. Please consider these comments.
    4. Chris Newman: Discuss [2008-09-25]: I'm concerned about the decision to overload the "CN=" field of the certificate subject with an EUI-48 or EUI-64 address. I understand this has pragmatic advantages. But an EUI-48/EUI-64 address is not a "Common Name". Further, I consider this a precedent that use of "CN" for MAC address is effectively best current practice for devices identified by MAC address. While I am OK supporting such a precedent based on the advice of this WG and lack of strong opinion from PKIX, I want to verify the rest of the IESG agrees before I clear my discuss.
    5. Tim Polk: Discuss [2008-10-08]: I believe this document needs to acknowledge a lying endpoint problem, especially with respect to firmware update. Specifically:
      The firmware update aspects of the CAPWAP protocol specification place a great deal of faith in the WTP. Specifically, the AC is trusting the WTP to assert the current firmware update, and to indicate whether the update has been installed. However, there is nothing in the CAPWAP protocol specification to indicate this level of trust in the WTP. I believe that a discussion of the trust model, and its limitations, should appear in this document. I would suggest introducing this concept in section 9, and expanding it in the security considerations.
      discuss-discuss: Is there a conflict between the guidance given in NAT Considerations Case 2 and the guidance in section 12.2
      Comment [2008-10-08]: I also support the naming aspects of Chris Newman's discuss position. To elaborate:
      The use of common name in section 2.4.4.3 is a rather non-standard use. In retrospect, it would have been better to use the serial number attribute, which is conceptually a closer match for the desired contents (the MAC address). I can accept the wg consensus, but believe the decision should be documented. I wish the capwap spec had permitted use of the serial number attribute as a transition strategy, since I believe that would be a better practice, but cannot really claim that it is best practice.
      Beyond the core of Chris' discuss, there are some interoperability concerns that should be addressed. The common name attribute is a directoryString, which can be encoded using any of several different string types. As described, the MAC address can always be encoded using a PrintableString. While I would suggest verifying this against the installed base, the specification should indicate which string type is used with the common name attribute to represent the MAC address.
    6. David Ward: Comment [2008-10-08]: I support the other discusses and will let them carry the block.
    7. Magnus Westerlund: Discuss [2008-09-24]: Section 2.4.4.3 There is formal syntax in this section without any reference to which syntax this is. Please include such a one.
      section 4.3: Fragment ID:I think the text does not make it clear if the fragment ID space is per direction and AC/WTP pair. I am also worried about the size of this field. It seems that if a large quantity of the packets needs fragmentation then this field will wrap within a segments lifetime
      Comment [2008-09-24]:
      Section 3.1: "If an AC permits the administrator to change the CAPWAP control port, the CAPWAP data port MUST be the next consecutive port number." This requirement seem to lack explicit reasons.
      Section 4.5.3: "If an older Request message (with smaller Sequence Number modulo 32) is received, it MUST be ignored." Smaller is not super obvious here.
      It is also possible to become out of sync with this if the sender of requests do what is not recommend and aborts transmission 16 times. I don't think there is a significant issue here. But a warning about this might with the SHOULD NOT abort sentence may provide good motivation.
      Section 4.5.2. Control Message Quality of Service "DSCP: The DSCP value of 46 SHOULD be used." The actual DSCP values use for a particular Per hop behavior (PHB) are suggested rather then required and are up to the adminstrative domain. Therefore you should indicate which which PHB you recommend and a reference to its definition. Also I don't understand why aren't using on of the assured forwarding classes instead of expedited forwarding class. Can you please provide some motivation for that?
      Section 4.6: What about type values 0, 65025-65535? What are they and should one care about them at all?
      Secton 4.6.14: "Note that this option is illegal is either the WTP or the AC uses IPv4." In addition to the is/if mistake it isn't really illegal but not defined?
      Section 9.1.1: I am a bit confused reading the description for how Image download is going to work. First to determine which is the first data of the image one needs to pay attention to the sequence or are there another mechanism for that? Secondly, there seem to be no way of indicating in the Image Data Request (CA->WTP) message the offset in the file of the data.
      I will take the freedom to extend on Lars' comment about the NAT traversal when AC behind NAT:
      Section 11., paragraph 4: " Because all communication originates at the WTP and is addressed to the AC, communication when the AC is behind a NAT will simply fail." Yes, the NAT one deployes a AC behind needs to have no incoming filters for this port. Otherwise it will not work. Usage of STUN like mechanisms appear to not work due to that the AC has no way of knowing when a WTP tries to contact it and from where. It needs to do that to be able to send filter rule establising packets.
      Section 11 and 9: Another issue with NATs that my read through don't think is covered in enough detail is the importance of the source address for the CA->WTP Image Data Request messages. For the CA behind NAT the same applies for the WTP data upload.

    Telechat:

  5. CAPWAP Protocol Binding for IEEE 802.11 (Proposed Standard)
    draft-ietf-capwap-protocol-binding-ieee80211-10.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-09-24]: I've commented the spec already during IETF last call, but there's one remaining issue that I'd like to discuss further:
      When TKIP or CCMP encryption is used, and WTP does the encryption, it obviously needs the key (TK) for TKIP or CCMP. However, currently the AC also sends two other keys, the EAPOL Key Confirmation Key (KCK) and Key Encryption Key (KEK), to the WTP, even though the WTP does not seem to need these keys for anything. The principle of least privilege would suggest that the AC shouldn't send these keys. Why not send just the needed keys? Or does the WTP need the KCK/KEK for something?
      Comment [2008-09-24]:
      Section 6.14: The 802.1p Tag field should be shown as 3 bits in the bit diagram, too.
      Section 6.23, should be "the third octet MUST value the value ' ', 'O', 'I', or 'X' as defined below" (there are four different values, none of which are 1, 2, or 3).
      Section 1 says 802.11n is not supported by this specification, but Section 6.25 defines a field for 802.11n?
      Section 8.1: the "Encryption Capabilities" field is now 16 bits, not 8.
      Section 8.1: there probably should be IANA considerations text about how the remaining bits are allocated
      Section 8.1 should say that there's no bit for WEP because all WTPs are required to support it (if that's the reason).
      Section 10.2 (Message Types): the range to be managed by IANA is not 32 bits, but only 8
      Section 10.2: message type 3398911 has Enterprise Number 13276, not 13277, so it's not part of the range to be managed by IANA.
      Section 10.5 (QoS) says values 0-4 are allocated in this specification, but Section 6.1 defines only values 0-3.
      Section 10.7 (Antenna Combiner) says values 0 and 1 are allocated in this specification, but Section 6.2 defines values 1-4.
      Section 10.8 (Antenna Selection) says values 1-4 are allocated in this specification, but Section 6.2 defines only values 1-2.
      Section 10.9 (Session Key Flags) , "bits two (2) through sixteen" should be "..through fifteen".
      Section 10.10 (Tagging Policy) says bits 5-7 are defined in this spec; but Section 6.22 defines bits 3-7.
      Section 10.12 (WTP Radio Type) says bits 5-7 are defined in this spec, but Section 6.25 defines bits 4-7.
    2. David Ward: Comment [2008-10-08]: Again support other DISCUSS positions
    3. Magnus Westerlund: Discuss [2008-10-08]: This is a question that I really would like to get answered before being certain about progressing this document.
      Section 2.6.1.2 "The IP header also includes the Explicit Congestion Notification (ECN) bits [RFC3168]. When packets received from stations are encapsulated by the WTP, the ECN bits are set to zero (0) in the outer header. The WTP does not modify the ECN bits in the original station's packet header. This mode of operation is detailed as the "limited functionality option" in [RFC3168]."
      Can you provide some reasoning why this section basically mandates the limited functionality option for ECN? I don't understand why full functionality would be a problem.

    Telechat:

  6. RTP Payload Format for ITU-T Recommendation G.711.1 (Proposed Standard)
    draft-ietf-avt-rtp-g711wb-03.txt
    Token: Cullen Jennings Note: Roni Even is the document shepherd
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-10-07]: <empty>
    2. Tim Polk: Comment [2008-10-07]: In section 5.3.1, example 2: The text for Offer says "with G.711 fallback" but does *not* include the lines
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      Aren't those were the lines that specify the G.711 codecs?
    3. Magnus Westerlund: Discuss [2008-10-08]: Section 8: please add a statement like:
      "The payload format or the codec data does not contain any type of active content such as scripts."
      Comment [2008-10-08]:
      Section 4.1: "The 5 most significant bits are reserved for further extension and MUST be set to zero." I suggest to add to the sentence: "and receivers MUST ignore them."
      Section 4.2: I am missing a statement that the frame must be consecutive. Obvious but not stated.

    Telechat:

2.1.2 Returning Items

  1. (none)

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. (none)

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. JWT Report on MPLS Architectural Considerations for a Transport Profile (Informational)
    draft-bryant-mpls-tp-jwt-report-00.txt
    Token: David Ward
    Extracted from Balloting:
    1. Ross Callon: Discuss [2008-10-09]: Section 1, fourth paragraph, last sentence. I was concerned that "the fears ... were allayed" could be mis-interpreted by some as "after investigation we found that there never was a problem". In fact, the issue is more that we found that the original fears were correct, but we put in place process changes that will result in the potential issues being avoided.
    2. Russ Housley: Comment [2008-10-07]:
      Section 1 says: "... a set of power point slides ..."; These slides are available only in PDF, so their original format is not important.
      Section 2: The final sentence of the section contains a missing reference. Please provide it.
    3. Tim Polk: Comment [2008-10-08]: A couple of nits...
    4. Magnus Westerlund: Discuss [2008-10-09]: IETF last call expires the 29th of October. Take the document off this weeks agenda?

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. Syntax for binding documents with time stamps (Informational)
    draft-santoni-timestampeddata-04.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-10-07]: discuss-discuss
      Can someone more clueful in this space illuminate how this documents intersects with RFC4998 coming out of LTANS? There seems to be some overlap between the twodocuments.
    2. Chris Newman: Comment [2008-10-08]: The "PrintableString" ASN.1 type doesn't permit all the characters that are permitted in a MIME media type. Of the US-ASCII set, only space, ctrls, and MIME tspecials are disallowed in a MIME media type. We have registered media types that use "_", which I don't think is permitted in PrintableString. You might want the ASN.1 type for mimeType to be IA5String. Also, what about media type parameters?

    Telechat:

3.3.2 Returning Items

  1. Guidelines for Using the Privacy Mechanism for SIP (Informational)
    draft-munakata-sip-privacy-guideline-04.txt
    Token: Jon Peterson Note: Proposing that this use RFC3932 Note 2
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-10-07]: Nit: Wouldn't the RFC3932 Section 4 clause 1 text be a bit more appropriate for an IESG Note, given that the draft has been discussed in SIP?
    2. Magnus Westerlund: Comment [2008-10-09]: Shouldn't our decision on response 2: be included in the RFC-editor Note section: "2. The IESG thinks that this work is related to IETF work done in WG <X>, but this does not prevent publishing."

    Telechat:

  2. MANET Autoconfiguration using Virtual Enterprise Traversal (VET) (Informational)
    draft-templin-autoconf-dhcp-16.txt
    Token: Ross Callon
    Extracted from Balloting:

    Telechat:

3.3.3 For Action

  1. PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics (Informational)
    draft-bberry-rfc4938bis-00.txt
    Token: Russ Housley
    Extracted from Balloting:
    1. (no balloting link)

    Telechat:

1233 EDT break

1239 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. Simple Authentication and Security Layer (sasl)
    Token: Pasi

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. Loa: structure for "active" liaisons, possibly drop some that are quite inactive
    RFCed model approved
    IRTF document approval process sent to RFCed
    starting process of electing IAOC rep
    host-config document out for comments

6. Management Issues

  1. Referencing Non-Standardized Technology in IETF Documents (Dave Ward)

    Telechat:

  2. Expert Review for tel reg (Cullen Jennings)

    Telechat:

  3. Large Interim Meeting in January 2009 (Russ Housley)

    Telechat:

  4. What does the IESG statement on SPAM control mean (Russ Housley)

    Telechat:

  5. FORCES (Mark)

    Telechat:

  6. v4v6 Interop (Magnus)

    Telechat:

7. Agenda Working Group News

1409 EDT Adjourned