IESG Narrative Minutes

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

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

Corrections from: Magnus, Dan, Tim

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. Session Initiation Protocol Call Control - Transfer (BCP)
    draft-ietf-sipping-cc-transfer-11.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-11-04]: Typo at the end of section 11.1: s/truck/trunk/
    2. Cullen Jennings: Discuss [2008-11-05]: Two things I want to talk about for the AIB in section 8
      It seems to me that having the multipart/signed inside the multipart/mixed is wrong because there are no other bodies in the mixed. It should just be a multipart/signed.
      I seem to recall checking the S/MIME signature long ago but I can't get it to parse any more. I might be extracting the binary representation in the wrong way. How are you doing this and I will try to duplicate.
    3. Chris Newman: Comment [2008-11-05]: I support Cullen's discuss about multipart wrapping. While a single-part multipart/mixed is legal MIME and in theory equivalent to moving the inner part up a level; in practice the extra wrapper tends to confound processing agents and UIs.
      So it's bad practice to misbehave when receiving a single-part multipart/mixed, but it's also bad practice to send it in the first place. While a "bad sending practice" example may be useful in specs to help receivers get more robust, it needs to be identified as a bad practice.
    4. Tim Polk: Comment [2008-11-04]:
      Section 5: s/he Transferee had initiated/the Transferee had initiated/
      Section 7.2: s/different that in current/different than in current/
      Section 7.5, Figure 9: I believe the Invite associated with dialog4 should be dialog3
      Section 7.5, Figure 10: I was confused by the messages associated with dialogs 3 and 4. I thought the final BYE/200 OK should be associated with dialog4 rather than dialog3.
      Section 7.6: s/to a race conditions/to race conditions/; s/In this, case the call flow/In this case, the call flow/
      Section 9, Figure 16: The figure omits dialog numbers.

    Telechat:

  2. EAP Generalized Pre-Shared Key (EAP-GPSK) Method (Proposed Standard)
    draft-ietf-emu-eap-gpsk-16.txt
    Token: Pasi Eronen Note: document shepherd: Joe Salowey
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-11-05]: I did find two minor sources of confusion, and if you can fix these it would be nice:
      "[A..B] extracts the string of octets starting with octet A finishing with octet B from the output of the KDF function." Presumably counting starts from 0?
      "EAP-GPSK provides protection against reflection attacks in case of an extended authentication because the messages are constructed in a different fashion." What is meant by "extended authentication" in this case?
    2. Pasi Eronen: Discuss [2008-11-04]: Holding a DISCUSS for IANA.
      Comment [2008-11-04]: Jouni Malinen's email on 2008-10-28 and Joe Salowey's SecDir review on 2008-11-03 identified couple of editorial nits.
    3. Chris Newman: Comment [2008-11-05]: It would be helpful to me if there was a discussion of how EAP-GPSK relates to EAP-TLS+TLS-PSK... Can general advice be given? Perhaps EAP-GPSK is preferred by default? Or perhaps EAP-TLS explicitly requires certificates and thus a new EAP code would be needed to use EAP-TLS-PSK?
    4. Tim Polk: Comment [2008-11-04]:
      The notation KDF_X(Y) is defined in Section 2 but is never used. KDF-X(Y,Z) [A..B] is defined in Section 4, and is used extensively.
      The definition for MK is given as "Master Key between the peer and the EAP server" which sounds very similar to the PSK. Consider expanding this definition to indicate that the MK is derived from the PSK, and is session specific.
      In Section 3, third paragraph from the end of the section describes the processing of GPSK-2... In addition to the MAC, the EAP server needs to verify that the parameters it included in GPSK-1 were correctly repeated in GPSK-2. Similar requirements extends to processing GPSK-3 by the peer
      Section 10: When processing GPSK-3, the processing rules do not involve ID_Server. Shouldn't the peer verify the ID_Server is the same as in GPSK-1 and GPSK-2?

    Telechat:

  3. The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-sips-08.txt
    Token: Cullen Jennings Note: The proto Shepherd for this document is Dean Willis
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-11-05]:
      ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
      Section 3.2., paragraph 1: Nit: s/securily/securely/
      Section 5.1.1., paragraph 6: Nit: s/emphasise/emphasize/ (also elsewhere)
      Section 5.4., paragraph 4: Nit: s/inconsistenty/inconsistently/
      Section 6.3., paragraph 2: Nit: s/Registar/Registrar/ (also elsewhere)
    2. Tim Polk: Discuss [2008-11-06]: The Security Considerations section for this document really needs to be expanded. At a minimum I would expect pointers to the security considerations in 3261, 4346, and ietf-sip-outbound. I would also like to see brief text reminding the reader that sips is not a guarantee that tls was used on every hop, although it is obviously redundant.
      Appendix A needs to be revised or dropped.
      Appendix B lacks context, but this can be supplied with a few introductory sentences.
      Comment [2008-11-06]: section 3.2: s/securily/securely/ ; s/inconsistenty/inconsistently/

    Telechat:

  4. Information Model for Packet Sampling Exports (Proposed Standard)
    draft-ietf-psamp-info-11.txt
    Token: Dan Romascanu Note: Juergen Quittek is the PROTO shepherd
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-11-06]: In Section 8.2.4 and 8.2.5, data type should probably be "unsigned32"
      The spec uses "quantity" semantics for many information elements that don't look like quantities, such as digestHashValue, hashDigestOutput, hashInitialiservalue, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, and mplsPayloadPacketSection,
      Appendix A says "The use of Namespaces as an extension mechanism implies that an IANA registered Namespace URI should be available..." IANA does register namespace URIs; see RFC 3688 for more information .
    2. Tim Polk: Comment [2008-11-04]: Section 8 states: "The Information Elements specified by the IPFIX information model [RFC5102] are used by the PSAMP protocol where applicable."
      The document does not provide any guidance on the subset of RFC5106 that is applicable to the psamp information model. Are implementations expected to support the entire IPFIX information model?
    3. David Ward: Discuss [2008-11-05]: DISCUSS DISCUSS: I don't understand from this document how to represent "errored packets." I see the packet sampling model and I see how psamp is passing errors but, the way to represent "I want to know information about errored packets" isn't explained.

    Telechat:

  5. Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) (Proposed Standard)
    draft-ietf-mmusic-qos-identification-02.txt
    Token: Cullen Jennings Note: Jean-Francois Mule is Proto Shepherd
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-11-06]: As an implementor of an application on a host acting as a, say, a SIP phone I do not not understand how these mechanisms are going to help me at all.
      First, how do I know if the underlying OS version supports NSIS, for instance? And even if I do know that, that says *nothing* about the support in the one place that truly needs it, namely in the routers in between. So all this appears to do is negotiation of mechanisms between two parties who have no clue about what mechanisms are available.
      Are there significant enough RSVP, NSIS, etc. deployments where specialized applications can actually make use of this?
    2. Lars Eggert: Discuss [2008-11-05]: ABNF doesn't validate. (See Tim's comment, plus it has two "attribute" defs.)
      Comment [2008-11-05]: Agree with Pasi on the example being invalid.
    3. Pasi Eronen: Comment [2008-11-04]: The example at end of Section 3 doesn't actually match the ABNF syntax (it's missing a space after the colon).
    4. Chris Newman: Comment [2008-11-06]: Agree with comments on ABNF/examples.
    5. Tim Polk: Comment [2008-11-04]: I don't think the following BNF in section 3 is quite right:
      qos-mech = rsvp / nsis / extension-mech
      extension-mech = token
    6. Dan Romascanu: Discuss [2008-11-02]: I am concerned by the lack of mention of operational implications related to the QoS negotiations made possible by the mechanism described in this document. There is always a chance that a common mechanism cannot be negotiated, and there is no indication what tools should be made available for such a situation.
    7. David Ward: Comment [2008-11-05]: agree with other discusses but, will let them carry
    8. Magnus Westerlund: Discuss [2008-11-05]: Section 3: ABNF error "attribute ="... ; Secondly I think the character spacing rule might be to tight that many will fail to use it correctly.
      Using RFC 4080 as a reference to NSIS QoS mechanism is a really poor choice. NSIS is a general signalling framework. Thus you actually need to reference the NSLP that does QoS negotiation: draft-ietf-nsis-qos-nslp-16

    Telechat:

  6. G.729.1 RTP Payload Format update: DTX support (Proposed Standard)
    draft-ietf-avt-rfc4749-dtx-update-02.txt
    Token: Cullen Jennings Note: Jean-Francois Mule is the PROTO Shepherd
    Extracted from Balloting:
    1. Tim Polk: Discuss [2008-11-04]: The Security Considerations section states: "The ability to interrupt transmission during silence periods is a well-known feature in RTP."
      I haven't a clue where to find more information on the type of vulnerability much less mitigation strategies.
    2. Magnus Westerlund: Discuss [2008-11-05]:
      Section 4: I am missing a statement that when using FT=14 there shall only be a single SID frame included in the RTP payload.
      Section 4: I am missing a statement that overrides the one in Section 5.4 of RFC 4749: "Only full frames must be considered..."
      Section 5.2.1: "A special rule applies for multicast: the "dtx" parameter becomes declarative and MUST NOT be negotiated..."
      I think the above text forgets the possibility to remove the payload type to indicate that the configuration is not supported.
      From Section 6.2 of RFC 3264: "The set of media formats in the answer MUST be equal to or be a subset of those in the offer..."
      I think the right approach is to say that if you understand in multicast that you don't support DTX that you should indicate this with removing the payload type in the answer. Here I think there is need for a backwards compatibility discussion. RFC 4749 is clear on that you shall ignore the reminder data that the SID frame will be when appended to a payload with other frames. Thus DTX can be run as long as the receiver doesn't react to badly to the missing frames. This happening actually becomes the most likely case for receivers that only implement RFC 4749 and are in multicast sessions. The ignore the unknown DTX parameter and accept the payload type.
      Section 7: I would like to point out that DTX may introduce a new security issue as it allows for determining the structure of the voice communicated even if encrypted.

    Telechat:

  7. Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) (Proposed Standard)
    draft-ietf-avt-dtls-srtp-06.txt
    Token: Cullen Jennings Note: The document shepherd is Roni Even
    Extracted from Balloting:
    1. Chris Newman: Discuss [2008-11-05]: Who is proposed as the designated expert for the new registry? RFC 5226 "Specification Required" means a designated expert needs to be chosen.
    2. Tim Polk: Comment [2008-11-06]: Section 4.2, immediately before Figure 1: A brief statement that the master key and master salt are provided to the SRTCP key derivation function seems to be missing here.
    3. Magnus Westerlund: Discuss [2008-11-06]: Section 4: there seems to be a significant mismatch between this document and the SRTP one. SRTP has crypto contexts that are identied by the triplet: SSRC, destination address and destination port Within each context there might be one or more master keys identified with the MKI if used. The DTLS-SRTP document seems to fail to take into account that the MKI and creation of crypto context (including the SRTP master keys) needs to be scoped by SSRC. The DTLS-SRTP document correctly discusses the forking issue when multiple DTLS handshake may happen and result in different DTLS contexts all delivering SRTP packets and DTLS messages to the same port. However, within each pairing there are only the DTLS client and the server, but there might be multiple SSRCs for each client and server. This doesn't seem to be covered. This might be a result in the failure to clearly connect the terminology between DTSL and SRTP.
      ...
      Comment [2008-11-06]: Section 3: "This improves the cryptographic performance of DTLS, but may cause problems when RTCP and RTP are subject to different network treatment"
      The above sentence seems so backwards. If you multiplex them together then they can't be subject to different treatment...

    Telechat:

  8. Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol (BCP)
    draft-ietf-behave-dccp-04.txt
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-11-05]:
      Section 2., paragraph 2: Nit: s/invidual/individual/
      Section 6., paragraph 1: Nit: s/Additionaly,/Additionally,/
      Section 7.2., paragraph 1: Nit: s/Futhermore,/Furthermore,/
    2. Cullen Jennings: Comment [2008-11-05]: Support Tim's Discuss
    3. Chris Newman: Comment [2008-11-05]: I recommend fixing this: "REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP." Does "it" refer to the NAT or to the ALG?
    4. Tim Polk: Discuss [2008-11-04]: The text for REQ-5 covering timeouts for session abandonment in section 5 and the corresponding security considerations seem in conflict. Section 5 mandates minimum timeouts of 124 minutes and 4 minutes for "established connection idle- timeout" and 'Transitory connection idle timeout" respectively. These MUST requirements are followed by a statement that the idle timeouts MAY be configurable. I interpreted the section 5 text as permitting configuration with larger values only, since the minimums are given as MUST statements. The security considerations section implies that the configuration may result in values smaller than the minimums specified in section 5. This means the MAY overrides the MUST statements?
    5. Dan Romascanu: Discuss [2008-11-05]: The document completly lacks requirements or any manageability consideration for the NATs that support DCCP. I assume that a network operator should have means to understand what is the support provided by the NAT and what modes are implemented and can be configured on a given device. What is the minimal mode and status information that needs to be exposed to an operator by a NAT supporting DCCP and how is this information accessed and configured on a NAT device?

    Telechat:

  9. Framework for Establishing an SRTP Security Context using DTLS (Proposed Standard)
    draft-ietf-sip-dtls-srtp-framework-05.txt
    Token: Cullen Jennings Note: Dean Willis will act as the proto shepherd
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-11-05]: ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280)
      Section 11., paragraph 0: Nit: s/Negotation/Negotiation/
      Section 1., paragraph 4: Nit: s/sigaling/signaling/
      Section 6.7.2., paragraph 1: Nit: s/appopriate/appropriate/
      Section 7., paragraph 3: Nit: s/especialy/especially/
      Section 8.6., paragraph 4: Nit: s/taht/that/
    2. Pasi Eronen: Discuss [2008-11-06]: The document needs some more text about how the responder's fingerprint is protected. In other words, how exactly the UPDATE messages and associated offer/answer works together with RFC 4474 and 4916 (the UPDATE message examples in RFC 4916 have an empty message body, and thus wouldn't protect the fingerprint).
      Comment [2008-11-06]: In Section 7, "a=fingerprint: \" suggests there's a space after the colon (":"); there isn't. I'd suggest breaking the line after "SHA-1" instead.
      RFC 3280 has been obsoleted by RFC 5280, and RFC 3546 has been obsoleted by RFC 4366.
    3. Russ Housley: Discuss [2008-11-05]: Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008. While it is a bit late, I would like to see a response to the "substantial" concern that is raised. I have not taken the time to determine if the man-in-the-middle attack is possible, and I hope the authors can quickly tell if there is a concern or not. If there is a concern, it needs to be corrected or documented in the security considerations.
    4. Tim Polk: Comment [2008-11-06]: The Introduction states that: "However, third party certificates MAY also be used for extra security." The limitations of that extra security should be addressed in the security considerations. To my mind, there is some degree of "defense in depth", but using third party certificates will not address any fundamental limitations of the protocol.

    Telechat:

  10. Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 (Proposed Standard)
    draft-ietf-vrrp-unified-spec-02.txt
    Token: David Ward
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-11-06]: Two of the issues relate to apparently missing information, and one may be either a simple mistake or I misunderstood something. I would like to talk about these on the call or with the authors.
      "Accept_Mode... Note: IPv6 Neighbor Solicitations and Neighbor Advertisements should not be dropped when Accept_Mode is False."
      "Compute and join the Solicited-Node multicast address [RFC4291] for the IPv6 address(es) addresses associated with the Virtual Router."
      Are these the only messages that should not be dropped?!... Is the idea that you actually do stop responding to RA/RS, and that by this hosts should migrate to to use the remaining router natively, rather than the remaining router as a backup for the dead one? If yes, say so.
      MLD is generally sent to multicast addresses, but RFC 3810 Section 5.1.15 also talks about a MUST requirement for a router to accept unicasted MLD. How is this accommodated in VRRP?
      What about the SEND certificate retrieval messages CPS/CPA? Lets say the primary router died just when a host had found it, but had not had time to ask for CPS/CPA. What will happen?
      7.4. IPv6 Interface Identifiers: "IPv6 Routers running VRRP MUST create their Interface Identifiers in >the normal manner (e.g., RFC2464 "Transmission of IPv6 Packets over Ethernet"). They MUST NOT use the Virtual Router MAC address to create the Modified EUI-64 identifiers."
      "If there are several VRRP routers, it is cumbersome for the operator to configure the same VRRP protected link-local address on all of them. An implementation might choose simplify this for the operator by using the VRRP MAC in the formation of these link local addresses."
      Isn't the former MUST NOT instruction contradictory with the guidance in the latter paragraph?>In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND)
      "[RFC3791] is deployed, VRRP authentication could be usefully added, because misconfiguration of secrets will not be an issue. Routers with different secrets will have different IPv6 addresses, and therefore there will be no issue with multiple masters with the same IPv6 (and MAC) addresses. Also, SEND will prevent malicious routers from sending misleading ND messages."
      As an author of RFC 3971 it is not quite clear to me what you mean above. First of all, no "secrets" are involved in RFC 3971, only key pairs for CGA addresses. Secondly, it is not required for routers to employ the CGA part of SEND; in most cases I would expect the configuration of certificates for prefix::1 or something like that. Thirdly, I do not understand why there is no issue, because the backup taking over, because then the backup has to authoratively sign the NAs and RAs it is sending, for the primary's address. If the "trust anchor and cga" mode from RFC 3971 is used, the private key would have to be shared, or this would not work at all. And private key sharing is not necessarily a good idea.
      Comment [2008-11-06]: Christian Vogt's review:
      The document uses the acronym "IPvX" in order to refer to both/either IP version. Since IPvX might be confused with the more prevalent acronym IPX for Novell's Internetwork Packet Exchange protocol, I would replace the occurrences of IPvX with either "IPv4 or IPv6", or simply with "IP".
      In the figures illustrating sample configurations in section 4, it is not clear which IP address labels denote a host's own IP address vs. which denote the IP address of the router that a host is using. Both is currently denoted "IPvX A" in the figure. Suggest distinguishing the two types of labels more clearly.
    2. Lars Eggert: Discuss [2008-11-05]: I'm holding this DISCUSS mostly until the issues raised in Mark Handley's tsv-dir review have been addressed.
      One further point:
      Section 11., paragraph 0: "Intellectual Property Rights Claimed" Is there a specific reason why the usual boilerplate text isn't sufficient for this document?
      Comment [2008-11-05]:
      Section 1., paragraph 2: "Comments are solicited and should be addressed..." Remove.
      Section 5.2.9., paragraph 4: "...IPv4 and IPv6 MUST NOT both be carried in one IPvX Address field." You probably want to add that a VRRP packet sent over IPv4 MUST contain IPv4 addresses in this field and a VRRP packet sent over IPv6 MUST contain IPv6 addresses. (In other words v6-in-v4 and vice versa is not allowed.)
      Section 6.4., paragraph 0: Throughout this section, I find the abbreviated text in the pseudocode comments (//) hard to read.
      Section 9., paragraph 0: Agree with Dan that this section doesn't seem to matter much. Move to appendix?
    3. Russ Housley: Comment [2008-11-04]: Vijay K. Gurbani made the following suggestions in his Gen-ART Review. They should be considered by the authors.
    4. Dan Romascanu: Discuss [2008-11-06]: (revised DISCUSS including input from OPS-DIR review by Pekka Savola)
      The version management and transition plan for VRRP is unlear to me... Should not this document update RFC 3768, and should not at least part of the migration and coexistence issues in Appendix A be moved to the Operational Issues section?
      I do not understand what is the logic of including a section 9 'Operation over FDDI, Token Ring, and ATM LANE' in this document.
      Accept_Mode defaulting to false seems unrealistic at least in deployments I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual address no longer responds to ping; Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position.
      Comment [2008-11-06]:
      Appendix B and part of Appendix C excepting the part refering to changes from RFC 3768 should be dropped at publication.
      Another feature that at least one vendor implements is so-called Backup VRRP router passive ARP learning. This is very useful, because otherwise when you switch from active to backup, the backup doesn't know ARP bindings for IP addresses and this increases the time needed to converge.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Modes of Operation for Camellia for Use With IPsec (Proposed Standard)
    draft-kato-ipsec-camellia-modes-09.txt
    Token: Tim Polk Note: document shepherd is Kato Akihiro
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-11-05]: Why isn't this coming via IPSECME?
    2. Pasi Eronen: Discuss [2008-11-05]: This document copies most of its text verbatim from RFC 4309 and 3686 -- and doesn't even acknowledge the source. I'd *strongly* suggest not copying it, and instead using a reference
      The document also needs to clearly define its relationship to RFC 4312 (which already defines how to use Camellia with IPsec/ESP, and how to negotiate it with IKEv1); it seems for CBC mode, the only thing needed is the IANA assignment in the IKEv2 registry (IKEv1 registry already has it).
      Process note: The document has a normative downref that wasn't called out during the IETF Last Call, and isn't listed in the DownRef registry. It was a normative reference in RFC 4312 and 4132, too, so probably just updating the DownRef registry would be enough.
      Comment [2008-11-05]: Idnits complains about unused references: [7], [8], [18], and [19]
      Section 3, the sentence "NIST has defined seven modes of operation..."; the number "seven" is already out of date, and will probably besoon after this is published.
    3. Chris Newman: Discuss [2008-11-05]: Every time we add yet-another symmetric cipher on the standards track, we create another code-path that could contain security bugs in deployed software and we create new opportunities for interoperability failures. While I do not object to registration of code points for what I consider to be vanity ciphers (anything other than IETF mandatory to implement or very widely deployed symmetric ciphers), the IANA registry for this is expert review and does not require a standards track document. I observe RFC 4308 was necessary to address the IPsec security algorithm smorgasbord problem and documents an IPsec WG consensus to minimize the number of named suites. I question if there is a real IETF consensus to make Camellia one of the fully standardized ciphers the IETF promotes.
      See also my discuss on draft-kato-camellia-ctrccm about cautionary text.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Combined User and Infrastructure ENUM in the e164.arpa tree (Informational)
    draft-ietf-enum-combined-08.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Lisa Dusseault: Comment [2008-11-04]: Why is this documenting a "potential solution"? Why is it Informational instead of Standards track? Is it recommended or not -- or do the providers who would implement it already know who they are?
    2. Lars Eggert: Comment [2008-11-05]: I have the same question that Lisa raised.
    3. Pasi Eronen: Discuss [2008-11-06]: A question: has this document been reviewed by the DNS directorate? In particular, I'm wondering if the use of DNAME records is consistent with current thinking about DNS, and with the currently deployed infrastructure? (That is, if DNAME records as described would be created, would the ENUM clients and caching DNS resolvers process them as intended?)
    4. Russ Housley: Comment [2008-11-05]: idnits 2.08.10 found three rather minor items...
    5. Tim Polk: Comment [2008-11-04]: I do wonder if the transition to the long-term solution will terminate as cleanly as specified here, though. The final sentence in section 6, Transition to the long-term Solution, states: "The domain name for the branch location and its DNAME record SHOULD be removed once the transition to the long-term solution is completed and all entities involved in I-ENUM have migrated to the new zone apex for I-ENUM." Will it ever be clear that "all entities" involved in I-ENUM have migrated to the new zone apex? If "all entities" means "all service providers" then perhaps we can make that determination, but if we interpert this as "all entities involved in making or answering DNS queries for I-ENUM" (as in the previous paragraph) then this seems problematic.

    Telechat:

  2. The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM (Informational)
    draft-ietf-enum-infrastructure-07.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2008-11-05]: Please add an RFC Editor Note that corrects the Intended Status" in the document.
    2. Pasi Eronen: Comment [2008-11-06]: I had big difficulties in understanding the document because it doesn't seem to specify anything (that could be implemented and used). The title certainly leads the reader to expect a technical specification describing an alternative to RFC 3761. However, it seems the document mainly describes the reasoning or motivation of why an alternative to RFC 3761 would be useful in some circumstances. The document title should be adjusted accordingly (perhaps "Motivation for Infrastructure ENUM" or something similar?).

    Telechat:

  3. Requirements and Analysis of Media Security Management Protocols (Informational)
    draft-ietf-sip-media-security-requirements-08.txt
    Token: Cullen Jennings Note: The Proto Shepherd is SIP WG chair Dean Willis
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2008-11-06]: Tero Kivinen's SecDir review identified some parts that would benefit from editorial improvements (such as giving pointers to specific sections of 5.* when discussing R-* in Sections 3 and 4).
    2. Russ Housley: Discuss [2008-11-05]: The Gen-ART Review by Elwyn Davies on 10-Oct-2008 has not been addressed. Elwyn ashed some questions, and I have not seen a response that offers answers to the questions.

    Telechat:

  4. Test vectors for STUN (Informational)
    draft-ietf-behave-stun-test-vectors-03.txt
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-11-03]: A clarifying question: is the user name in Section 2.4 before SASLprep processing or after?
      It would be useful to show the password in Section 2.4 also after SASLprep processing (it seems this particular string is changed by SASLprep)
    2. Tim Polk: Comment [2008-11-05]: I am comfortable with the technical content in this draft, but find the Abstract and body of the text internally inconsistent. It seems that the scope kept expanding as the authors progressed through the document, but never revised the front matter. Specifically, the Abstract implies that there are only two STUN attributes that can appear in STUN messages. The Introduction indicates that there are two STUN attributes that include hashes in STUN messages, and that these are in the sample messages. Section 2, Test Vectors, notes that the three most problematic STUN attributes are FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS and the document has test vectors for each of these attributes. An additional message covers STUN authentication with long term credentials. From the Abstract and Introduction, I am afraid the reader will not realize the full scope of the test vectors and may not perform some appropriate tests.

    Telechat:

  5. AS Number Reservation for Documentation Use (Informational)
    draft-ietf-idr-as-documentation-reservation-00.txt
    Token: David Ward
    Extracted from Balloting:
    1. Russ Housley: Comment [2008-11-05]: Why not a BCP?
    2. Dan Romascanu: Discuss [2008-11-05]: Why is this document targeting Informational? We seem to have an inconsistent approach for documents that define names/values for fields used as examples.

    Telechat:

3.1.2 Returning Items

  1. Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) (Informational)
    draft-ietf-smime-bfibecms-10.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Sam Hartman: Discuss [2007-11-28]: "The RFC822email is the e-mail address of the recipient in the format defined by [TEXTMSG]. E-mail addresses that contain non-ASCII characters MUST be encoded using punycode [PUNYCODE]." Is this consistent with how we're handling email internationalization for local parts?
    2. Chris Newman: Comment [2007-12-19]: John Klensin noticed this while reviewing the document and my discuss text:
      The references in this document are a mess. The two I spotted immediately are that, while Brandner is a significant figure around the ITU community, he is not the author of RFC 2119 and Dave Crocker is not the author of 2822, nor does 2822 have the same title as 2821. I'm on an airplane and can't check, but I suspect that [DER] is similarly botched, with a mismatch between author, title, and date (and it is insufficiently specific for the pointer from the text).

    Telechat:

  2. Identity-based Encryption Architecture and Supporting Data Structures (Informational)
    draft-ietf-smime-ibearch-09.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2007-11-28]: This specification indicates the use of HTTP GET and POST without clarifying what level of HTTP support is required of clients and servers.
      The use of three-digit response codes within HTTP responses, that are different from HTTP status codes, is confusing... What HTTP status code should be used in the first line of the response, when the body contains an IBE error, is not clear. There are no examples of error responses.
    2. Sam Hartman: Discuss [2008-03-11]: I support Chris, Lisa and Cullen's discusses.
      How does a key server know whether a user is authorized to use a particular identity address?
      I find the use of application/octet-stream and the use of xhtml completely inappropriate in sections 3 and 4.
      According to the protocol public parameters are needed to decrypt the message. How does this work when you try to decrypt a historic message? What if the public parameters have changed?
      How is interoperability achieved if implementations "MAY REQUIRE" certain extensions to function? Shouldn't we require that implementations have a mode that works with no extensions?
      How do you know what district to use for a given email address? How do you know where to find the parameters? How do you authenticate that a given public parameters server is allowed to speak for a given district?
    3. Cullen Jennings: Comment [2008-11-03]:
    4. Chris Newman: Comment [2008-11-05]: I support Lisa's discuss.
    5. Tim Polk: Discuss [2008-03-18]: [picking up Sam's discuss]
      How does a key server know whether a user is authorized to use a particular identity address?
      I find the use of application/octet-stream and the use of xhtml completely inappropriate in sections 3 and 4.
      According to the protocol public parameters are needed to decrypt the message. How does this work when you try to decrypt a historic message? What if the public parameters have changed?
      How is interoperability achieved if implementations "MAY REQUIRE" certain extensions to function? Shouldn't we require that implementations have a mode that works with no extensions?
      How do you know what district to use for a given email address? How do you know where to find the parameters? How do you authenticate that a given public parameters server is allowed to speak for a given district?

    Telechat:

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Considerations for Having a Successful BOF (Informational)
    draft-narten-successful-bof-03.txt
    Token: Russ Housley
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2008-11-06]: One of the points of the document is to advocate early preparation for the BOF. However, the timelines listed in the document do not match current reality: I would suggest an edit: s/((one)|(1)) month/six weeks/
    2. Pasi Eronen: Comment [2008-11-05]: Would it be useful to say more about what happens after the face-to-face BOF session?... Another topic is how to define the scope... One aspect is that if there already are detailed protocol specifications as Internet-Drafts, the authors of those drafts are not necessarily very good in answering the question "what's the problem being solved by your draft" in a way that others would grasp... A second aspect is that one person's problem can be somebody else's solution. If the draft authors say they're solving A, you can always ask what's the problem B being solved by solving A?...
      Some additional minor comments: In couple of places, the document says the deadline for scheduling BOFs is approximately one month prior to the IETF meeting; for recent IETFs (IETF 72 and 73), it's been 6 or 7 weeks. The document has several URLs pointing to pages on www.ietf.org. It's quite possible that the currently ongoing website redesign project will break them.
    3. Russ Housley: Discuss [2008-10-27]: I saw constructive Last Call comments from Spencer Dawkins, Dave Crocker, and Gonzalo Camarillo. I have not see responses to any of them. Please provide responses, even if it is to indicate the reason that their suggestions are not going to be accepted.
    4. Tim Polk: Comment [2008-11-05]: I have issues with both the structure and content of item 3) "asking the wrong question" in Section 4, "Pitfalls".
      First on structure, Item 3) includes a half page list of the *right* questions to ask during a BOF. I think this is extremely important material, and entirely misplaced. I believe it should be moved to Section 3, "The BOF Itself".
      The following is an excerpt from the opening paragraph in item 3): "Often, BOF organizers feel like there is a need to ask the question "shall we form a WG?". But, unless the question is clear, properly scoped, etc., asking such a question serves no purpose. Even worse, such questions can demonstrate that there is no consensus (yet) for the work and thus no WG should be formed." I have real issues with the last sentence in the quoted text, "Even worse..."

    Telechat:

  2. Camellia Counter mode and Camellia Counter with CBC Mac mode algorithms (Informational)
    draft-kato-camellia-ctrccm-04.txt
    Token: Tim Polk Note: document shepherd is Kato Akihiro
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-11-06]: Agree with Pasi's Discuss.
    2. Pasi Eronen: Discuss [2008-11-04]: Section 3.2 is basically copied verbatim from RFC 3686, Section 3.3 is verbatim from RFC 3610, and Section 5 again from RFC 3686. Instead of repeating over 8 pages worth of complex technical text, I'd suggest just replacing this with pointers to RFC 3686 and 3610 (or the NIST specs for these, SP 800-38A and SP 800-38C).
    3. Chris Newman: Discuss [2008-11-05]: I would like to have a discussion with the IESG about the issue of vanity crypto algorithms. I think we should have boilerplate either in the form of an IESG note or text in the draft that points to the algorithms that should be implemented first for the sake of interoperability.

    Telechat:

  3. Suite B Profile for Transport Layer Security (TLS) (Informational)
    draft-rescorla-tls-suiteb-10.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2008-11-05]: I've reviewed this document earlier, but re-checking version -10 vs. RFC 5246 found couple of nits (and one errata for RFC 5246, unfortunately -- RFC Editor errata ID #1585).

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. Congestion Control in the RFC Series (Informational)
    draft-irtf-iccrg-cc-rfcs-07.txt
    Token: Lars Eggert
    Extracted from Balloting:
    1. (none)

    Telechat:

3.3.2 Returning Items

  1. (none)

1313 EDT break

1319 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:

  2. Low Extra Delay Background Transport (ledbat)
    Token: Lars

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

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

    Telechat:

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

    Telechat:

5. IAB News We can use

  1. neither Olaf nor Loa
  2. Russ: can't think of anything needing to be reported

6. Management Issues

  1. Message to IANA regarding address range reservation for IETF protocols (Russ Housley)

    Telechat:

  2. Large Interim Meeting Agenda (Russ Housley)

    Telechat:

  3. New Geopriv co-chair (Cullen Jennings)

    Telechat:

  4. Use of WebEx technology at IETF experiment in Minneapolis and Malta (Dave Ward)

    Telechat:

  5. Mail List Management (Russ Housley)

    Telechat:

  6. Liaison to IEEE 802.1 (Dan Romascnu)

    Telechat:

  7. http://emergency.ietf.org/ (Russ Housley)

    Telechat:

7. Agenda Working Group News

1415 EDT Adjourned