IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-01-29. These are not an official record of the meeting.

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

Corrections from: Magnus, Russ, Ross, Dan, Tim

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. GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations (Proposed Standard)
    draft-ietf-geopriv-pdif-lo-profile-14.txt
    Token: Cullen Jennings Note: Robert Sparks is proto shepherd
    Extracted from Balloting:
    1. (none)

    Telechat:

  2. NEMO Management Information Base (Proposed Standard)
    draft-ietf-mext-nemo-mib-05.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Chris Newman: Discuss [2009-01-28]: The DateAndTime textual convention for SNMPv2 does not require the use of an interoperable format that includes a timezone offset. Some uses of the DateAndTime textual convention remedy this problem with specific language. For example, RFC 2591 states the following when using the DateAndTime textual convention:
      DESCRIPTION "... An implementation MUST return all 11 bytes of the DateAndTime textual-convention so that a manager may retrieve the offset from GMT time."
      Would such text be appropriate for this usage? Or is this usage a case where an up-to-25 hour skew between client and server interpretation of the time will not be a problem?
      I'll clear my discuss if such text is added or if the authors assert the 25-hour skew is not a problem for this usage.
    2. Dan Romascanu: Comment [2009-01-28]:
      nemoBindingMrFlag OBJECT-TYPE
      • SYNTAX TruthValue
      • MAX-ACCESS read-only
      • STATUS current
      • DESCRIPTION "true(1) indicates that the binding cache entry is froman entity acting as a mobile router.false(0) implies that the binding cache entry is froman entity acting as a mobile node."
      But the TC in RFC2579 says:
      TruthValue ::= TEXTUAL-CONVENTION
      • STATUS current
      • DESCRIPTION "Represents a boolean value."
      • SYNTAX INTEGER { true(1), false(2) }
      So it should be false(2) and not false(0) in the DESCRIPTION clause.

    Telechat:

  3. Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management (Proposed Standard)
    draft-ietf-radext-management-authorization-06.txt
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-29]: This spec is overall in very good shape. However, I had the following problems:
      Section 5.3 says on Management-Policy-Id attribute:
      "The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is RECOMMENDED that the message contain UTF-8 encoded 10646 [RFC3629] characters."
      The statement about not affecting the operation of the protocol is at least misleading and confusing and likely also factually wrong. Like the document states earlier:
      "If the NAS supports this attribute, but thepolicy name is unknown ... the NAS MUST treat the Access-Accept packet as if it had been an Access-Reject."
      So the contents of the field can actually have an effect even at the RADIUS level. I would suggest saying something else, e.g.,
      "It is intended to be human readable and the contents MUST NOT be parsed by the receiver; the contents can only be used to look up locally defined policies."
      Comment [2009-01-29]: I find it unfortunate that the document does not define an attribute to distinguish SSH and other forms of command line protocols from each other. Or has such an attribute already been defined somewhere else?
      The document is silent on exactly how authentication from, say, SCP or is actually represented in RADIUS. Perhaps that is obvious? (But aren't there non-trivial details, depending on what kind of challenge or password mechanism is in use?) Or is authorize-only used?
      I support Pasi's Discuss.
    2. Lars Eggert: Comment [2009-01-27]: 
                                           |    |     |SHLD| MUST|    |
    Attribute Name        Value Type |MUST| MAY | NOT|  NOT|Encr|

      Don't abbreviate RC2119 terms: s/SHLD/SHOULD/.
    3. Russ Housley: Comment [2009-01-28]: In the Gen-ART Review by Vijay Gurbani on 11-Nov-2008, he asked a question:
      S5.3: Below the figure, the Length is shown as ">= 3". However, the Text field expects "one or more octets..." Should not the Length then be ">= 1"?
    4. Tim Polk: Discuss [2009-01-29]: [Note that I am not requesting any changes at this time! I am interested in discussing this issue (with authors, chairs, and other ADs) to determine if it merits action...]
      The Management-Privilege-Level Attribute supports differentiated privilege levels denoted by integer values. The specification notes that "specific access rights conferred by each value are implementation dependent".
      Almost inevitably, implementations begin by assigning values in ascending or descending order but find a need to assert a new privilege level in the middle at a later date. That works fine with this specification, but product vendors sometimes make an assumption that this will be ordered.
      I wonder if a brief addition to the security considerations noting that vendors should not assume ordering for these values would be worthwhile?

    Telechat:

  4. Update for RSAES-OAEP Algorithm Parameters (Proposed Standard)
    dr draft-ietf-pkix-rfc4055-update-01.txt aft
    Token: Pasi Eronen
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-29]: This is a good spec, but there were two easily correctable problems.
      1. First, Section 2 says: "CAs that issue certificates with the id-RSASSA-PSS algorithm identifier SHOULD require the presence of parameters in the subjectPublicKeyInfo algorithm field if the cA boolean flag is set in the basic constraints certificate extension."
        By reading this, it is not clear to me if you are talking about something that the CA should do for the certificate it is creating, or if it needs to verify something from the certificate request. Either way, the text should probably be written slightly differently to make it clear to implementors what they need to do. For instance, "... SHOULD include parameters ..." or "... in the subjectPublicKeyInfo algorithm field of the certificate request, if ..."
      2. Secondly, Sections 3 and 4 introduce changes where the presence of a field goes from SHOULD include to MUST NOT include. By reading the writeup I understand that this does not have interoperability implications, as it has not been implemented anyway (but it speaks only about CAs, what about hosts?). Could you add a sentence or two to the document to say the same thing? The writeup is not easily accessible for anyone reading the RFC later.

    Telechat:

  5. Softwire Mesh Framework (Proposed Standard)
    draft-ietf-softwire-mesh-framework-05.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-01-27]: You use the acronym AFBR before you define it.
    2. Russ Housley: Comment [2009-01-28]: The Gen-ART Review by Francis Dupont that was posted on 15-Dec-2008 says:
      The document is very unpleasant to read and have some editorial nits:
      • page 1: too many authors (proposal: keep editor(s) and add a section with the full list of authors. It is a common problem so the solution should be well known)
      • Abstract page 2: too long
      • Abstract page 2: the position of softwire mesh vs general overlay is not explained (but as the Abstract is already too long...)
      • 3.1 page 8: figure 1 has some nits (just fix them or warn the RFC editor)
      • 3.2 page 10: same for figure 2 with more nits
      • 5 page 13: in the E-IP family, and -> in the E-IP family, (i.e., keep only the last "and")
      • 5 page 14: i.e. -> i.e.,
      • 7 page 16: core, send the packet -> core, then send the packet
      • 10.1 page 18: the [RFC4378] -> [RFC4378]
      • 10.1 page 19: trade offs -> trade-offs ?
      • 10.1 page 19: verses -> versus
      • 11.1 page 20: unbounded -> unbound ?
      • 11.2 page 23: Lan-Like -> LAN-Like (or LAN-like)
      • 14.1 page 24: playback -> replay
      • 14.3 page 28: (the only technical issue) there is no more a "main mode" in IKEv2. BTW the text seems to mandate preshared keys when IMHO it requires only automatical SA establishment (better than key distribution).
      • Authors' page 30: too many authors
    3. Tim Polk: Discuss [2009-01-28]: Julien Laganier's secdir review (posted 16 December, 2008) raised several significant issues that have not been resolved.
    4. Dan Romascanu: Discuss [2009-01-29]: The OPS-DIR review by Pekka Savola posted" on 12/17 raised a number of issues. Despite the dialog that followed the review, none of them was addressed with editorial proposals. Specifically I think that the following issues from the OPS-DIR review need clarification:
      1. My main concern here is with the O&M implication of dynamically created and used softwires, which do not run any routing protocol and there is no IETF protocol or management framework which could be used to verify the correct operation of these tunnels. Essentially this seems to require that operators deploy about N (where N is the number of connected sites) data probing hosts which periodically test connectivity with the N-1 other probes. Or this could be implemented with proprietary mechanisms at AFBR routers.
        Softwires do not run BGP keepalives and do not (apparently) run IGP protocol. As a result, it seems difficult for the network operator to notice when/if connectivity through a softwire no longer works. (Previously, BGP or IGP timeouts were an indicator for this.)
        This is discussed in Section 10 (some further comments on this below). They key point there seems to be that there are ways how an operator could build monitoring to the softwires, but the IETF protocols do not seem to provide a protocol solution for this (while they do provide such a solution for manually configured tunnels for example).
        This seems like a significant drawback of this solution and I'd like to see O&M aspects addressed better in the softwires framework.
        -- I did not see any proposal for clarification by text or references of this issue.
      2. In S 10: Examples of techniques applicable to softwire OAM include:
        o BGP/TCP timeouts between AFBRs
        o ICMP or LSP echo request and reply addressed to a particular AFBR
        ... BGP/TCP take a very long time, and their usage only verifies I-IP signaling path between the endpoints, not data plane. And what about ICMP or LSP echo -- this is not clear whether it's run over the softwire or using I-IP; I'm assuming they are not run on top of softwire.
        As a result they are not very useful from OAM perspective. Given that no IGP is run on top of softwires, debugging E-IP connectivity issues seems quite painful. This is exacerbated by the fact that forwarding decisions to softwire are done by "policy", not by longest prefix matching. I.e., your O&M connectivity test procedures also need to test that this policy is working OK, and testing needs to be done from locations accepted by the policy. What you probably need is to build some kind of N^2 matrix of data probes (using 1500B packet size or like) through the core to verify that all softwires are opering correctly. As a result, I'm having great doubts about O&M (reliability, debuggability, "is it working or not?" indications) aspects of this technology.
        -- Some explanations were provided in responses by Eric Rosen but I did not see any proposal for clarification by text or references of this issue.
      3. In S 5 (this is also bordering on architectural issue):
        "This leads to the following softwires deployment restriction: if a BGP Capability is defined for the case in which an E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST advertise that capability."
        ... is there any way an implementation could verify if this deployment restriction holds not not? For example, if one of the routers doesn't happen to support this capability, how will this be detected by the network operator?
        -- Some explanations were provided in responses by Eric Rosen but I did not see any proposal for clarification by text or references of this issue.
      4. The document does not describe MTU and fragmentation/reassembly issues in the core network at all. In this kind of service my assumption is that you need to support 1500B packets at ingress when DF-bit is set or the packet is IPv6. Discussion in RFC4459 seems applicable here. The operational solution to this problem is the requirement to provision the core network with larger MTUs so that all 1500B+encapsulation overhead can be supported throughout the core. This needs to be discussed in the text.
        -- This issue was acknowledged by Eric in one of his responses but I did not see any proposal for clarification by text or references.
      5. Also, in S 4.1:
        "The AFBRs handle both I-IP and E-IP. However, only I-IP is used on AFBR's "core facing interfaces", and E-IP is only used on its client-facing interfaces.
        ... At some point, a client might want to upgrade to dual stack. Then, client-interface may use both E-IP and I-IP. This solution should be applicable then as well (just that mesh tunnels won't be used for I-IP from a client port). I think it is, but this needs to be made clear.
        -- Eric acknowledged that depending on policy, one might or might not want to do, e.g., v6/v6 or v4/v4 encapsulation, but considered the issue out of charter. Pekka clarified that the issue is client behavior atupgrades from v4-only to dual-stack, and that the issue is important from an operational point of view and needs clarification. I did not see any proposal for clarification by text or references.
      6. In the case where E-IP is IPv4 and I-IP is IPv6, it is possible to do this translation algorithmically. A can translate the IPv4 S and G into the corresponding IPv4-mapped IPv6 addresses [RFC4291], and then B can translate them back. The precise circumstances under which these translations are done would be a matter of policy.
        ... But the corresponding IPv4-mapped IPv6 address for G is not a multicast address because it does not start with FF00::/8, and I suspect as a result all implementations will treat such a G address as a unicast address. I guess one could fix this by standardizing a group mapping to use some multicast prefix under ff00::/8 and encode the v4 address in the bottom bits.
        -- The issue was acknowledged in the response from Eric, but I did not see any proposal for clarification by text or references.

    Telechat:

  6. BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute (Proposed Standard)
    draft-ietf-softwire-encaps-safi-04.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-29]: This is a good document, and I was almost ready to vote Yes on it. However, I noticed this:
      "Inclusion of this sub-TLV depends on the tunnel type. It MUST be encoded for L2TPv3 tunnel type. On the other hand, the protocol type sub-TLV is not required for GRE tunnels."
      What about IP-in-IP? The specification should be complete... perhaps you should have said "... On the other hand, the protocol type sub-TLV is not required for IP-in-IP or GRE tunnels."
      Comment [2009-01-29]: The document says:
      "For example, the path from R1 to R2 may be part of a "BGP-free core", where there are no BGP-distributed routes at all in the core."
      Reference defining the BGP-free core concept would be nice. Not sure if there is a suitable reference, though.
    2. Pasi Eronen: Discuss [2009-01-29]: There has recently been some discussion about processing of optional transitive attributes that are recognized but somehow malformed. This document probably should say something about the situation. E.g. whether malformed Tunnel Encapsulation Attributes would cause a NOTIFICATION and tearing down the BGP connection (the default), ignoring the UPDATE, or ignoring the attribute, or possibly something else.
    3. Tim Polk: Discuss [2009-01-28]: I could not determine which features are mandatory to implement for this specification.
      Since there are multiple mechanisms to communicate certain information (i.e., support for GRE without key), this could result in two "compliant" implementations that support different mechanisms and are not interoperable.
      As I understand it, BGP speakers that only support GRE without key could use the extended community attached to UPDATE and would not need to ever generate the encapsulation SAFI. However, BGP speakers that supported multiple encapsulation protocols *including* GRE without key might choose to use the Encapsulation SAFI and omit the GRE encapsulation sub-TLV (as described in section 4.1). At least in the case of GRE without key, it seems that support for both features is needed to ensure interoperability.

    Telechat:

  7. BGP IPSec Tunnel Encapsulation Attribute (Proposed Standard)
    draft-ietf-softwire-encaps-ipsec-01.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-29]:
      The abstract says: "Currently support for GRE and L2TPv3 tunnel types are defined. This document defines support for IPsec tunnel types."
      The newest version of the SAFI document actually defines IP in IP, too.
      The document says: "Let R1 and R2 be two BGP speakers that may send data packets through R3, such that the data packets from R1 and from R2 may be received by R3 over the same interface. Then if R3 has sent an update containing an Encapsulation SAFI, and if this update specifies an IPsec tunnel type, and if this update is received by R2, and an Encapsulation-SAFI with an IPsec tunnel type, SHOULD also be received by R1."
      Where is the SHOULD referring to? Is this a statement that if one router receives a message it is also expected to be received by another one? But BGP works in a p2p manner, so I don't see how this is guaranteed. Or is this a statement that one of the routers need to do something special, such as send Encapsulation AVPs? If so, maybe the "SHOULD be received" needs to be rewritten somehow.
      But maybe I'm missing something here.
      The document says: "IPsec does not necessarily need to be required for control packets that are directly addressed to R3."
      If BGP is used to negotiate that IPsec is needed on a particular tunnel interface, it seems that it is impossible for that instance of IPsec protection to protect BGP. Chicken and egg problem. Of course, you could configure IPsec separately to protect BGP. My experience is that if you do not tell the reader how the IPsec policies are setup, the chances are that its not possible to set them up :-)
    2. Lars Eggert: Comment [2009-01-28]: Section 2., paragraph 4: "- IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5 [RFC4023]"
      I think this reference should be to RFC2003 (or at least not to RFC4023, because that doesn't talk about IP-in-IP at all.)
    3. Pasi Eronen: Discuss [2009-01-29]: I have reviewed draft-ietf-softwire-encaps-ipsec-01. Overall, the document looks good, but I have the following concerns that I'd like to discuss before recommending approval of the document:
      - The document describes how the tunnel initiator (R1 in Section 3) authenticates R2 (using the hash from the sub-TLV), but says nothing about how R2 authenticates R1.
      - The tunnel type values (3..6) identify some aspects of the IPsec SA that will be used to protect the traffic, but not how the IPsec SA is actually created. Probably IKEv2 is meant, but we have (at least) three other IPsec key management protocols as RFCs (IKEv1, KINK, and Photuris). If it's not always IKEv2, the protocol to be used probably should be given in some sub-TLV.
      - The draft needs some text describing the SPD and PAD entries needed for IKEv2 negotiation to succeed. I think this should be relatively straightforward (once authenticating R1 is solved somehow).
      Smaller comments:
      - If the IKE exchange will always use certificates (possibly self-signed), I'd suggest using normal SHA-1 certificate fingerprints (what e.g. web browsers and other management systems currently display -- hash over entire certificate) instead of the RFC 4306 approach (hash over SubjectPublicKeyInfo structure only).
      On the other hand, IKEv2 also has a "Raw RSA Key" type (although no corresponding "Raw DSA Key" or "Raw ECDSA Key" types), which could be used without generating self-signed certificates. But perhaps the ability to use other algorithms than RSA makes certificates attractive here.
      - Values 5 (IP-in-IP with IPsec transport mode) and (MPLS-in-IP with IPsec transport mode) don't identify which IPsec protocol (ESP or AH) is to be used. This is probably OK, as AH vs. ESP can be negotiated by IKE -- but then we don't need two separate values 3 and 4 either.
      - The text probably should allow more than one IPsec Tunnel Authenticator sub-TLV in one attribute -- otherwise, it will be difficult to ever change the key or certificate (or introduce new Authenticator Types) without disrupting traffic. In this case, if the certificate (or key) presented in IKE matches one of the sub-TLVs, that would be considered successful.
      - It seems RFC 4306 (and other key management protocols, if they're supported) should be a normative reference.
    4. Chris Newman: Comment [2009-01-28]: It would be helpful to name both the registry "BGP" and the sub-registry "Tunnel Encapsulation Attribute Tunnel Types" or "Tunnel Encapsulation Attribute Sub-TLVs" to help readers find the relevant IANA registries.
    5. Tim Polk: Discuss [2009-01-28]: Julien Laganier's secdir review (16 December, 2008) has not recieved a response. I have appended the body of the review to this discuss for expediency. I support his suggestion to add text about the tunnel types in the security considerations. I also found the highlighted text in section 3 confusing.

    Telechat:

  8. BGP Traffic Engineering Attribute (Proposed Standard)
    draft-ietf-softwire-bgp-te-attribute-04.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-01-29]: Please fix the email address for Yakov to be @juniper.net instead of @juniper.com as listed in the draft.

    Telechat:

  9. Advertising an IPv4 NLRI with an IPv6 Next Hop (Proposed Standard)
    draft-ietf-softwire-v4nlri-v6nh-02.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-01-28]: The Gen-ART Review by Gonzalo Camarillo posted on 8-Dec-2008 raised a few minor concerns that ought to be addressed:
      The acronym NLRI should also be expanded in the title of the draft.
      The Requirements Language Section could be moved to a new section after the Introduction (i.e., new Section 2). Right now it is located after the Abstract.
      Section 1, first sentence: reference RFC 4760 does not need to be in brackets.
      RFC 2434 has been obsoleted by RFC 5226.

    Telechat:

  10. Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode (Proposed Standard)
    draft-ietf-tls-psk-new-mac-aes-gcm-05.txt
    Token: Pasi Eronen Note: Document Shepherd is jsalowey@cisco.com
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-01-28]: The Gen-ART Review by Robert Sparks posted on 22-Jan-2009 raised a few editorial comments that ought to be addressed:
      1) In the applicability statement, consider pointing to (or moving forward) the statement in 4279.
      2) The IANA considerations section should name the registry (btw - where are the instructions to IANA on how to choose the next numbers?)
    2. Chris Newman: Comment [2009-01-28]: It would be helpful to add an informative reference to a definition of the term "Perfect Forward Secrecy." That term has a technical meaning that may differ from a layman's interpretation of the words. RFC 4949 may be a suitable reference.
    3. Tim Polk: Comment [2009-01-27]: I don't quite follow the second paragraph of the security considerations:
      "As described in [RFC5288], the cipher suites defined in the Section 2 of this document may only be used with TLS 1.2 or greater. The cipher suites defined in the Section 3 may be used, whatever the negotiated TLS version is."
      Is the point that cipher suites defined in section 3 provide slightly more cryptographic security if version 1.2 has been negotiated, since we are using a stronger hash in the PRF? As written, this paragraph restates an interoperability issue (already rasied in 1.1) rather than a security consideration.

    Telechat:

  11. A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer (Proposed Standard)
    draft-ietf-mmusic-file-transfer-mech-10.txt
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-01-29]: This is related to the context-sensitive grammar issue, but I have an additional problem. ABNF parsers actually fail to parse the ABNF here:
      filetype-selector = "type:" type "/" subtype *(";"parameter)
      Comment [2009-01-29]: I too would have wanted to see negotiation of existing file transfer mechanisms as opposed to a new one. Is this mechanism deployed, and have the other IM protocols done for the same functionality? There may of course be reasons why an integrated file transfer mechanism is needed.
    2. Chris Newman: Discuss [2009-01-28]: The following ABNF:
      filetype-selector = "type:" type "/" subtype *(";"parameter) ; parameter defined in RFC 2045
      results in a grammar that is extremely context-sensitive. The RFC 2045 "parameter" ABNF allows free insertion of linear-white-space (including comments and line folding), so the following would be legal:
      type:foo/bar;blatz=( hash:sha-1:... ) hash
      In addition, the variant of quoted string used for parameter values by RFC 2045 allows a construction such as: type:foo/bar;blatz="\" hash:sha-1:.." In the two examples above, the "hash:sha-1" is part of the comment or parameter value, not a selector.
      If this really is your intention, I recommend adding some examples showing the degenerate parsing cases so people following the spec can test their parsers. Otherwise, updates to the ABNF may be appropriate to simplify these cases.
      Comment [2009-01-28]: I'm concerned by the creation of yet-another-file-transfer mechanism. As if we didn't have enough with FTP, SFTP, SCP, TFTP, HTTP, RCP, RSYNC, etc. Did the authors evaluate reusing existing file transfer technology and enhancing it to support the missing features, as necessary? I can perhaps see the justification for some of the SDP negotiation, but this is a very monolithic architecture rather than a more traditional Internet component-based architecture. This seems to be re-inventing a traditional IETF application.
      I'm also concerned by the complexity of this architecture, particularly given that it potentially mixes generic file transfer in the same stream with IM traffic and IM attachments creating a potentially nasty content dispatching problem as well as a multiplexing problem (something that has deployed poorly in the applications layer with SSH being perhaps the sole exception of a widely deployed/used channel multiplexing technology at that layer).
      Although I'm not a huge fan of our media feature standards due to their complexity, they are the standards we have for cases where one endpoint is requesting content that meets certain characteristics from another endpoint. Why were these existing standards not used? Was reuse at least evaluated? I note the lemonade WG was specifically constrained to reuse media features by its charter so there are people who feel strongly about this in the IETF community. The lemonade WG ended up reusing the feature tag registry, although not the rest of the framework based on complexity evaluation.
      I'm putting these three issues in a comment as I don't see them as actionable and thus will not hold a blocking discuss over these issues (although I may choose to abstain on this document after IESG discussions).
    3. Tim Polk: Comment [2009-01-28]: Section 5, para 3 sentence 2
      s/selects those file/selects those files/
      Section 10, last sentence
      s/to dismiss the risk of damage/to mitigate the risk of damage/
      (if you don't like mitigate, limit or reduce would work, too!)
    4. Magnus Westerlund: Comment [2009-01-28]:
      C1. Section 6: ABNF errors
      attribute = file-selector-attr / file-disp-attr / file-tr-id-attr / file-date-attr / file-icon-attr / file-range-attr ;attribute is defined in RFC 4566
      This would if combined with the RFC 4566 ABNF override the attribute definition which I don't think the intention is. One way to express this correct would be to use the /= between the rulename and the rule extension.
      filetype-selector = "type:" type "/" subtype *(";"parameter)
      There is a missing white space between ";" and parameter
      C2. Section 6: I think there might be good to be clearer in the text around the below sentence that all 160 bits of the SHA-1 output is included:
      Implementations according to this specification MUST add a US Secure Hash Algorithm 1 (SHA1) [RFC3174] value if the 'hash' selector is present.

    Telechat:

2.1.2 Returning Items

  1. IEEE 802.21 Mobility Services Framework Design (MSFD) (Proposed Standard)
    draft-ietf-mipshop-mstp-solution-11.txt
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lars Eggert: Comment [2008-09-25]:
      Section 6.1., paragraph 4: The only delay with TCP (assuming Nagle is turned off) is the connection setup delay
      Section 6.2., paragraph 1: TCP backs off if there is packet loss, and yes, performance may degrade. But UDP is no magic bullet, either - delivery over UDP is unlikely to be more timely than with TCP.
      Section 6.3., paragraph 3: UDP will only be faster if much more aggressive timers are used here, which is problematic. I'd like to request that the text around what timers values are permissible be tightened using 2119 language.
      Section 6., paragraph 1: Given the reliability requirements, shouldn't this text REQUIRE MIH ACKs with UDP and say they MUST NOT be used with TCP?
      Section 6.3., paragraph 2: See above, I think your reliability requirements make this a MUST.
      Section 6.1., paragraph 5: The PUSH bit is not under the control of an application that uses TCP. I believe you mean that the Nagle algorithm (RFC896) should be disabled.
      Section 6.2., paragraph 3: "If MIHF knows the RTT, the rate can be based upon this" How?
      Section 6.3., paragraph 1: "For TCP, the retransmission timeout is adjusted according to the measured RTT. However due to the exponential backoff mechanism, the delay associated with retransmission timeouts may increase significantly with increased packet loss." And that is a *feature* - it's why Internet congestion control works.
    2. Pasi Eronen: Discuss [2009-01-29]: Two of the four scenarios (described in Section 3) talk about running this protocol across multiple administrative domains, possibly even over the general Internet.
      I don't think leaving how to use this securely for future work (or proprietary solutions) is OK in a Standards Track RFC, and does not meet the requirements of BCP61.
      Realistically, this draft cannot fix the situation, so I propose publishing this as Experimental instead (with strongly worded IESG note). While there can be valid reasons to grant exceptions to BCP61, I do not think "some folks prefer to do protocols first and think about security later" is one of them, even when "some folks" come from another SDO.
      However, if other ADs do not share my opinion, I am willing to move to "Abstain".
    3. Russ Housley: Discuss [2009-01-28]: The Gen-ART Review by David Black was posted on 27-Jan-2009, and Jari has indicated that the concerns raised ought to be addressed. Please update the document or provide RFC Editor notes.
    4. Cullen Jennings: Comment [2009-01-28]: Support PASI discuss.
    5. Chris Newman: Comment [2008-10-16]: I support Pasi's discuss. TLS has shown to be a deployable privacy solution in the real world. In addition to privacy, it includes authentication support that works in some scenarios or when combined with SASL/EAP/HTTP-auth or some other authentication framework), but it has lots of knobs that have to be specified when a protocol chooses to use it. We've had some mistakes when binding it to application protocols that caused real deployment problems and had to be corrected (the most notable is allowing "STARTTLS" to be advertised as a capability by a server even if no server certificate is installed).
      I strongly recommend getting this right early rather than botching it and having to work around bad deployment practices.
    6. Tim Polk: Comment [2008-09-25]: [I have cleared my discuss and moved this to a comment after discussion with the sponsoring AD...]
      Section 5 puts a lot of effort into differentiating between MoS discovery for MoSh, MoSv, and MoS3. However, I was surprised to find that these terms never appear in the remainder of the document. That is, the transport options in section 6, transport flows in section 7, and security considerations in section 8 only refer to MoS in general. I would think that the source of my mobility services would impact the selection of a transport, and would have security implications. (I don't think it impacts the flow, though. Is that correct?)
      Perhaps the implications are all second-order (e.g., MoS3 discovery using IS implies longer messages which has impacts MIH message Size in 6.1 and rate in 6.2) ?
    7. David Ward: Comment [2008-09-25]: I will let the others hold the discuss but, they must be cleared.
    8. Magnus Westerlund: Comment [2008-11-04]: (empty)

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Common Architecture Label IPv6 Security Option (CALIPSO) (Proposed Standard)
    draft-stjohns-sipso-06.txt
    Token: Tim Polk
    Extracted from Balloting:
    1. Ron Bonica: Discuss [2009-01-27]: Could you explain why the problem that you are solving can't be addressed with any of the existing VPN technologies (e.g. L3VPN).
    2. Lars Eggert: Discuss [2009-01-29]: I'll shortly summarize my points from the discussion in Minneapolis. First, I believe that creating IP options (esp. a hop-by-hop options) for walled-gardens is inappropriate. We've been pushing back when other SDOs wanted to do this. I see no reason why this case is different. A second concern is that this proposal resurrects historic IPv4 technology for IPv6, when we have better protocol mechanisms available that would address the same set of requirements (cf. Ron's comment on VPN). Third, this draft is not just asking for an IP option number. It changes many more pieces of the architecture, e.g., how applications interact with transport protocols. Finally, there was no serious attempt to engage the IETF community on their strong last call comments. Pretty much the only change was to move the document to Informational, which is essentially irrelevant, because what matters is that an IP option number will be allocated by an IESG approval.
      I'd like to discuss these issues on the call, to see if I'm on the rough side of the consensus here. I'll move to an abstain afterwards.
    3. Pasi Eronen: Discuss [2009-01-29]: I support Lars's and Ron's discusses.
      From the discussion so far, I also get the impression that we might not have IETF Consensus for the approach proposed in this document.
      Adding to Lars's concern about transport protocols: In this draft, there can be multiple simultaneous TCP connections with the same five-tuple (proto, src, dst, src port, dst port). That probably means updating every middlebox in the network that uses the five-tuple for its state -- and possibly many protocols that use addresses/port numbers to identify connections (anything from RSVP to SDP to ICE to BGP flow specs to RADIUS NAS-Filter-Rule attributes). That sounds bad.
    4. Russ Housley: Discuss [2009-01-28]: The Gen-ART Review by Elwyn Davies was posted on 28-Jan-2009. The IANA related comment must be addressed before the document can be approved. The other comments deserve consideration as well.
      s9.2: The authors have requested IESG assistance with the IANA considerations section. The section does not currently have a well defined allocation policy (it is sort of FCFS with expert review on the side).

    Telechat:

  2. Vouch By Reference (Proposed Standard)
    draft-hoffman-dac-vbr-05.txt
    Token: Russ Housley
    Extracted from Balloting:
    1. Chris Newman: Discuss [2009-01-13]: I find this specification elegant in its simplicity and its functional separation from the signature mechanism (DKIM/SRP/etc), and certainly my initial impression is that this should be advanced on the standards track.
      I have three concerns I believe the authors could address relatively easily.
      1. If this technology deploys widely and is used in the way people are likely to use it (increasing spam score on messages which are not vouched for), it will create the opportunity for monopolistic vouch-for services with a great deal of power over point-to-point email communications. Such a situation would clearly cause harm to the Internet. While there's little a technical specification like this can do to prevent that, it can at least provide guidance to consumers of the service that could reduce the chance of monopolistic practices. Here's a quick attempt at a paragraph along these lines, although I'd be satisfied by any similar text:
        If a recipient selects one or more vouch-for domains, and uses the results of vouching to adjust spam scores on incoming email, that recipient is placing a great deal of operational trust and power in the selected vouch-for service operators. Recipients are strongly encouraged to select such services with care. Further, recipients are strongly encouraged to select more than one vouch-for service to avoid a single-point-of-failure and to avoid placing excessive trust and power in a single vouch-for service operator.
      2. Section 4: "All three header fields in the VBR-Info header are mandatory. In particular, there is no default for the md= domain."
        This is incorrect terminology, a "header field" is defined by section 2.2 of RFC 5322. I believe you meant to say "header parameters" or "parameters" if you want to avoid confusion.
      3. Section 4.1: Every place where "*FWS" appears in the ABNF, I believe you want "[FWS]" instead. The "*FWS" construction violates the MUST NOT in RFC 5322 section 3.2.2.

    Telechat:

  3. Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-loreto-simple-im-srv-label-03.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. (none)

    Telechat:

  4. The Sieve mail filtering language - extensions for checking mailbox status and accessing mailbox metadata (Proposed Standard)
    draft-melnikov-sieve-imapext-metadata-08.txt
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2009-01-28]: The abstract and introduction talk only about accessing mailbox/server annotations, but the document also defines an extension for checking mailbox status and creating mailboxes when needed. This should be mentioned in the abstract and introduction.
    2. Russ Housley: Discuss [2009-01-28]: There was a discussion following the Gen-ART Review posted by Spencer Dawkins pm 13-Dec-2008. I expected to see an update to the document based on that discussion, but there has not been one. There are not any RFC Editor notes either.
      Here is the point that I expected to be covered in the document:
      RFC 5228 (Sieve base) doesn't describe how Sieve scripts are stored and how to handle failure to retrieve them - this is out of scope for both documents. However I can add an example of what I meant here - if a Sieve script is stored in LDAP and the script can't be retrieved when a message is processed, then the agent performing Sieve processing can, for example, assume that the script doesn't exist, or delay message delivery until the script can be retrieved successfully. Annotations should be treated as if they are a part of the script itself, so a temporary failure to retrieve them should be handled in the same way as a temporary failure to retrieve the Sieve script itself.
    3. Tim Polk: Comment [2009-01-29]: I support Russ's discuss: I believe that the text Alexey proposed adding in his January 20 message (To Spencer Dawkins cc'ed to ietf@ietf.org) would be a useful addition.
      I have no other issues with this document...

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. SPEERMINT Terminology (Informational)
    draft-ietf-speermint-terminology-17.txt
    Token: Jon Peterson
    Extracted from Balloting:
    1. (none)

    Telechat:

  2. Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement (Informational)
    draft-ietf-trill-prob-05.txt
    Token: Mark Townsley
    Extracted from Balloting:
    1. Russ Housley: Discuss [2009-01-28]: The TSV Directorate Review by Bernard Aboba was posted on 26-Nov-2008, and it includes some suggestions to make Sections 2.6 and 3.5 much stronger. There was no reply to the review, and the document was not revised after the review. Please consider these comments.
      Comment [2009-01-28]: The Gen-ART Review by Francis Dupont posted on 27-Nov-2008 included some editorial comments.
      - 2.1 page 4 (twice): Mbps -> Mbits/s ?
      - 2.3 page 6: perhaps the RSTP abbrev should be introduced (IMHO it is far from to be necessary)?
      - 5 page 14: SEND was published some years ago so why you said it is "under development"?
      - Author's Addresses -> Authors' Address
      - +1 (310) ... -> +1 310 ... (according to ITU-T E.123)

    Telechat:

  3. The RPF Vector TLV (Informational)
    draft-ietf-pim-rpf-vector-08.txt
    Token: David Ward
    Extracted from Balloting:
    1. (none)

    Telechat:

  4. ECDHE_PSK Ciphersuites for Transport Layer Security (TLS) (Informational)
    draft-ietf-tls-ecdhe-psk-05.txt
    Token: Pasi Eronen
    Extracted from Balloting:
    1. Chris Newman: Comment [2009-01-28]: It would be helpful to add an informative reference to a definition of the term "Perfect Forward Secrecy." That term has a technical meaning that may differ from a layman's interpretation of the words. RFC 4949 may be a suitable reference.
    2. Tim Polk: Discuss [2009-01-28]: The second paragraph of the security considerations is misleading, IMHO. The document states:
      "Given the current state of published to date crypto attacks, HMAC-SHA1 apparently is not (yet) so bad that we need to risk breaking interoperability with previous versions of TLS. However, implementers and administrators should monitor the general statements on recommended cryptographic algorithms published from time to time by various forums including the IETF, as a base for the portfolio they support and the policies for strength of function acceptable for the cipher suites they set."
      I agree wholeheartedly with the second and third sentences, but the first is unnecessarily negative. To my knowledge, no one has dinged HMAC-SHA1 yet. (For example, the Wang attack does not impact the security of a SHA-1 based HMAC.) I am not a cryptographer (and it's been snowing in Washington so I can't even ask one right now...) but I think the security achieved with HMAC-SHA1 is the security one would get from an HMAC constructed with an ideal hash function with a 160 bit output!
      The phrase "is not (yet) so bad" implies that HMAC-SHA1 is on its last legs. I would like to see this sentence softened considerably.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture (Informational)
    draft-andreasen-sipping-rfc3603bis-07.txt
    Token: Cullen Jennings Note: Mary Barnes is proto shepherd
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-01-28]: The Gen-ART Review by Francis Dupont was posted on 24-Dec-2008. Please consider the editorial concerns that were raised.
      - Abstract page 2: please remove (SIP) [RFC3261] (the Abstract is an autonomous text, the abbrev is not used so is useless, etc)
      - ToC page 3: Acknowledgements -> Acknowledgments
      - 1 page 5: this is the right place to introduce the SIP abbrev, i.e., SIP -> Session Initiation Protocol (SIP) [RFC3261]
      - 2 page 6: the DCS abbrev is never introduced
      - 5 page 10: the UAC abbrev is not introduced, IMHO you should find a way to introduce UAC and UAS abbrevs in 3 (Trust Boundary).
      - 5.1 page 11: .The trace-param -> . The trace-param
      - 8 page 25: ccc-id -> cccid (for uniformity)
      - 8.3 page 28: The UAC may also include a P-DCS-Redirect header.
      -> The UAC MAY also include a P-DCS-Redirect header. (IMHO according to the context this should be the uppercase keyword)
      - 8.5 page 28: .Otherwise, -> . Otherwise,
      - 12 page 37: Acknowledgements -> Acknowledgments
      - 12 page 37: Tung- Hai -> Tung-Hai ?
      - 13.2 page 38: please use the long names for months (first 4 entries)
    2. Cullen Jennings: Comment [2009-01-24]: Comments from GEN Art some minor editorial concerns (i.e, to be fixed bt the RFC Editor):
      • Abstract page 2: please remove (SIP) [RFC3261] (the Abstract is an autonomous text, the abbrev is not used so is useless, etc)
      • ToC page 3: Acknowledgements -> Acknowledgments
      • 1 page 5: this is the right place to introduce the SIP abbrev, i.e., SIP -> Session Initiation Protocol (SIP) [RFC3261]
      • 2 page 6: the DCS abbrev is never introduced
      • 5 page 10: the UAC abbrev is not introduced, IMHO you should find a way to introduce UAC and UAS abbrevs in 3 (Trust Boundary).
      • 5.1 page 11: .The trace-param -> . The trace-param
      • 8 page 25: ccc-id -> cccid (for uniformity)
      • 8.3 page 28: The UAC may also include a P-DCS-Redirect header.
        The UAC MAY also include a P-DCS-Redirect header. (IMHO according to the context this should be the uppercase keyword)
      • 8.5 page 28: .Otherwise, -> . Otherwise,
      • 12 page 37: Acknowledgements -> Acknowledgments
      • 12 page 37: Tung- Hai -> Tung-Hai ?
      • 13.2 page 38: please use the long names for months (first 4 entries)

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

3.3.3 For Action

  1. Analysis of Inter-Domain Routing Requirements and History (Historic)
    draft-irtf-routing-history-09.txt
    Token: Ross Callon
    1. (no balloting link)

    Telechat:

  2. A Set of Possible Requirements for a Future Routing Architecture (Historic)
    draft-irtf-routing-reqs-10.txt
    Token: Russ Housley
    1. (no balloting link)

    Telechat:

1304 EDT break

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

4.2.2 Proposed for Approval

  1. Network Configuration (netconf)
    Token: Dan

    Telechat:

  2. IP Performance Metrics (ippm)
    Token: Lars

    Telechat:

5. IAB News We can use

  1. Loa: meeting yesterday, I wasn't there for whole meeting. Two things: I-D/Boilerplate, should go out this week; agreement on SF plenary, arranging for presentors
  2. Russ: also there was the appeal response.

6. Management Issues

  1. IESG Statement regarding chartered work overcome by events before IESG consideration (Ron Bonica)

    Telechat:

  2. draft-cam-winget-eap-fast-provisioning-10.txt (Russ Housley)

    Telechat:

7. Agenda Working Group News

1422 EDT Adjourned