IESG Narrative Minutes

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

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

Corrections from:

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. Management Information Base for OSPFv3 (Proposed Standard)
    draft-ietf-ospf-ospfv3-mib-15
    Token: Ross Callon
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-07-15]: idnits highlights that RFCs 3414 and 3415 exist in the references but are not not cited in the text. This will need to be fixed before RFC editing is complete.
    2. Tim Polk: Comment [2009-07-13]: Two minor editorial nits in section 6 (security considerations):
      in paragraph 1: s/by this MIB may result/by this MIB module may result/
      in paragraph 2: s/MIB allows the discovery/MIB module allows the discovery/

    Telechat:

  2. HTTP Enabled Location Delivery (HELD) (Proposed Standard)
    draft-ietf-geopriv-http-location-delivery-15
    Token: Cullen Jennings; Note: Richard is PROTO shepherd. Please do not DEFER this draft
    Extracted from Balloting:
    1. Alexey Melnikov: Discuss [2009-07-13]: This is a well written document. There are 4 relatively minor points that I would like to discuss with authors/shepherd/IESG before recommending approval of this document:
      1). The document normatively references RFC 2818 for server TLS identity verification.
      RFC 2818, Section 3.1 says:
      "Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com."
      This allows for wildcard like f*.com (i.e. the leftmost component is not just "*"). I don't believe this is a recommended procedure for wildcard matching and other application protocols don't allow it. So I would like to discuss what should be recommended in this case.
      2). In Section 6.5.2 ("expires" Parameter):
      "The "expires" attribute is only included in a "locationResponse" message when a "locationUriSet" element is included. The "expires" attribute indicates the date/time at which the Location URIs provided"
      This doesn't specify if the date/time is in local timezone, in UTC, or is allowed to be either. I believe local timezone might cause some minor interoperability problems, as the Device would have to discover server's timezone.
      I would encourage using the last paragraph of draft-hollenbeck-rfc4930bis-02.txt, Section 5 to address this issue, or argue why other formats should be allowed.
      (Note, if you choose to disallow local timezone, you also need to fix your examples).
      2b). COMMENT: As fractional seconds seem to be allowed in the "expire" attribute, it would have been nice to have an example of this.
      3). In Section 6.3 ("code" Parameter):
      "The value of the response code MUST be one of the following tokens:"
      This make it sound that the list of error codes is not extensible, yet you establish an IANA registry for them.
      4). "application/held+xml" MIME type registration was sent to ietf-types@iana.org mailing list for review in April 2008:
      <http://eikenes.alvestrand.no/pipermail/ietf-types/2008-April/002028.html>
      However none of the comments raised on the mailing list were addressed or responded to:
      <http://eikenes.alvestrand.no/pipermail/ietf-types/2008-April/002030.html>
      <http://eikenes.alvestrand.no/pipermail/ietf-types/2008-April/002029.html>
      Comment [2009-07-13]:
      6.4. "message" Parameter
      "The "error" message MAY include one or more "message" attributes to convey some additional, human-readable information about the result of the request. The message MAY be included in any language, which SHOULD be indicated by the "xml:lang", attribute. The default language is assumed to be English."
      I suggest added to the end of last sentence:
      ("en") [RFC4646bis]"
      11.3. MIME Media Type Registration for 'application/held+xml'
      "Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8."
      Does this have any interaction with HTTP, which uses ISO-8859-1 by default?
      "Interoperability considerations: This content type provides a basis for a protocol"
      This doesn't really say anything about interoperability. The write-up implies that there are multiple implementations of the protocol already, so you can just say it here.
         Additional Information:  Magic Number(s): (none)
            File extension(s): .xml
            Macintosh File Type Code(s): (none)
      

      I think this should be the same as in RFC 3023: Macintosh File Type Code(s): "TEXT"
    2. Tim Polk: Discuss [2009-07-16]:
      The text in section 8 on client authentication seems correct in the context of the features defined within this specification, but may not be true when HELD extensions are defined. Specifically, the recommendations against authentication are arguably sound so long as the IP address is the only identity type supported. However, section 5.1 indicates that additional identity types are expected to be defined in the future.
      I believe paragraph 3 of the http bindings text should be revised to apply this guidance to the case where the device identity is the IP address and specifically note that extensions to support other Device identities may introduce new authentication requirements.
      Comment [2009-07-16]:
      I found the last statement in section 5.1 confusing:
      "The LIS MUST ignore any part of a location request message that it does not understand, except the document element."
      This begs the obvious question, if you don't recognize the document element and do not ignore it, what do you do? I eventually sorted it out from the following code parameter definition in section 6.3:
      "unsupportedMessage: This code indicates that an element in the XML document for the request, was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver."
      I would suggest either covering this case in the first sentence of section 5.3 or adding a note in 5.1 that points to 6.3.
    3. Dan Romascanu: Discuss [2009-07-15]: This is a very well written document and I know a lot of work was invested to make it meet the requirements, and a lot of controversy was overcome on the road. A few items still seem to me to REQUIRE clarification:
      1. In a review of a previous version Bernard Aboba raised the issue of client authentication. This resulted in changes which look like did not improve the situation, but quite the opposite.
      The previous text related to LIS behavior (e.g. not refusing authorization based on lack of authentication). In athat text, the LIS could challenge the client, but was restricted in its options if the client failed authentication. In the new text, the LIS is recommended not to even try to authenticate the client. I cannot understand how this can be allowed. A DoS threat from one or several clients choking a LIS with dummy requests is not part of the threat model?
      A compromise approach would be for the LIS to make the choice on whether to challenge the device based on the nature of the request. Devices only supporting requests that cannot be challenged (e.g. requests utilizing implicit IP address identification) could omit support for HTTP authentication. However, if a device were to make a request of another type (e.g. utilizing HELD extensions), the LIS could challenge it and therefore the device would need to support HTTP authentication. This should be at least an option in my view.
      2. The document lacks completely any information about how LIS's supporting HELD would be managed. What needs to be configured on a LIS? are there any statistics kept on the number of requests, number of succesful requests, errors, errors distribution, etc. made available to operators that need to include a LIS in his/her network? How can an operator know when a LIS gets near to its capacity and the resulting performance starts to degrade?
      3. I have a hard time understanding what the following paragraph in Section 4.1.2 means:
      " LIS operators have a large role in ensuring the best possible environment for location determination. The LIS operator needs to ensure that the LIS is properly configured with identifiers that fall within NATs and VPNs. In order to serve a Device on a remote side of a NAT or VPN a LIS needs to have a presence on the side of the NAT or VPN nearest the Device."
      What means 'identifiers that fall within NATs and VPNs'? How 'a presence on the side of the NAT or VPN nearest the Device' is achieved by a LIS?
      Comment [2009-07-15]:
      1. How can [I-D ietf-geopriv-l7-lcp-ps] be just an Informational Reference? Maybe at least the defibition of a LIS should be replicated here.
      2. In 4.1.1
      "To minimize the impact of connections or tunnels setup for security purposes or to traverse middleboxes, Devices that connect to servers such as VPN servers, SOCKS servers and HTTP proxy servers should perform their HELD query to the LIS prior to establishing a connection to other servers."
      I think s/should/SHOULD/

    Telechat:

  3. Connection Reuse in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-connect-reuse-13
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-07-13]: I found the last paragraph of section 3 confusing:
      "While this is adequate for TCP, TLS connections can be reused to send requests in the backwards direction since each end can be authenticated when the connection is initially set up. Once the authentication step has been performed, the situation can thought to resemble the picture in Figure 1 except that the connection opened from A to B is shared; when A wants to send a request to B, it will reuse this connection, and when B wants to send a request to A, it will reuse the same connection."
      I suggest simply striking the first phrase as I'm not sure what "adequte for TCP" means. In the second paragraph, I suggest replacing "except that the connection opened from A to B is shared" with "except that A and B both use a single shared connection, for example, between port 8293 on A and port 5061 on B". Clearer yet, but not necessarily worth the effort, would be a new figure 3 illustrating the single shared connection.
      The normative behavior in the first and third paragraphs of section 8.1 seem to use "SHOULD" and "MUST" to describe the same behavior.
    2. Adrian Farrel: Comment [2009-07-15]:
      The terms "Alias" and "Persistent connection" look like nouns but are defined as verbs.
      Section 8.1 and 8.2 are unclear on exactly how long a connection should be retained after its last use terminates. The text appears to state that an implementation must not close a connection unless it experiences some form of resource shortage. Isn't this a bit extreme?
      Surely this should be reflected in Section 8.3
      Section 8.1
      "The proposed mechanism uses a new Via header field parameter. The"
      The mechanisms is no longer "proposed" it is real.
      Seciton 8.3
      "Either the client of the server may terminate a TLS session by"
      s/of/or/
    3. Russ Housley: Comment [2009-07-13]: In the Gen-ART Review by Suresh Krishnan, he suggest an update to Section 3. The example ephemeral ports used (8293 & 9741) do not correspond to ephemeral ports in most well known OS implementations. Please use ones from the suggested IANA range: IANA suggests 49152 to 65535.
    4. Alexey Melnikov: Discuss [2009-07-09]: This is a fine document. I have some blocking comments, but they are minor and probably can be resolved during the IESG telechat next week:
      8.1. Client Behavior
      "Clients MUST authenticate the connection before forming an alias; Section 9.1 discusses the authentication steps in more detail. Once the server has been authenticated, the client MUST cache, in the alias table, the identity (or identities) of the server as they appear in the X.509 certificate subjectAlternativeName extension field."
      This can be read as contradicting section 7.1 of draft-ietf-sip-domain-certs-04, which says:
      "2. If and only if the subjectAltName does not appear in the certificate, the implementation MAY examine the CN field of the certificate. If a valid DNS name is found there, the implementation MAY accept this value as a SIP domain identity."
      8.2. Server Behavior
      "Servers SHOULD authenticate the connection before forming an alias. Section 9.2 discusses the authentication steps in more detail."
      This is weaker than the requirement on clients in section 8.1. I think this should be a MUST.
      Comment [2009-07-09]: 5. Overview of Operation
      "6. The network address inserted in the "Destination IP Address" column is the source address as seen by P2 (i.e., the "received" header field parameter). It could be the case that the host name of P1 resolves to different IP addresses due to round-robin DNS. However, the aliased connection is to be established with the original sender of the request."
      In Section 8.1:
      "This behavior has an adverse side effect when a CANCEL request or an ACK request for a non-2xx response is sent downstream. Normally, these would be sent over the same connection that the INVITE request was sent over. However, if between the sending of the INVITE request and subsequent sending of the CANCEL request or ACK request to a non-2xx response, the connection was reclaimed, then the client SHOULD"
      What is the meaning of "reclaimed" in this case?
      8.2. Server Behavior
      "If the sent-by production of the Via header field contains a port, the server MUST use it as a destination port. Otherwise the default port is the destination port."
      Use for what? As the port number to be added to the alias table?
      9.1. Authenticating TLS Connections: Client View
      "When a TLS client establishes a connection with a server, it is presented with the server's X.509 certificate. Authentication proceeds as described in Section 5 of RFC YYYY [I-D.domain-certs]."
      Should this be section 7.3 ("Client behavior")?
      9.2. Authenticating TLS Connections: Server View
      "A TLS server conformant to this specification MUST ask for a client certificate; if the client possesses a certificate, it will be presented to the server for mutual authentication, and authentication proceeds as described in Section 6 of RFC YYYY [I-D.domain-certs]."
      Should this be section 7.4 ("Server behavior")?
    5. Robert Sparks: Discuss [2009-07-15]: In the context of a proxy that is authoritative for more than one domain:
      The example in Section 9.3 on Virtual Servers focuses on the impact on processing at P2 (describing its alias tables). The document would benefit from adding a short description of what's happening in P1, noting that P1 would need to either keep separate alias tables for the work it does as example.com and example.net, or keep sufficient state in the alias table to know which of the two connections it has to P2 should be used.

    Telechat:

  4. Addressing Record-Route issues in the Session Initiation Protocol (SIP) (BCP)
    draft-ietf-sip-record-route-fix-07
    Token: Robert Sparks; Note: Nils Ohlmeier is the document shepherd
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-07-13]: Nit: I can't parse the last paragraph in section 3.2. My OS X dictionary widget doesn't have a definition for "enlights". "This is why, these techniques..." What is "this" and what are "these techniques"?
    2. Adrian Farrel: Discuss [2009-07-15]: All my discuss points are relatively minor, but I would appreciate a little effort to polish the document in these areas.
      Abstract
      I can't parse:
      "It is just not possible to make one header having the characteristics of both sides at the same time."
      I assume...
      s/It is just not possible/It is not possible/
      and...
      s/having/have/
      .. but what sides are you refering to?
      I'm not happy with the division between normative and informational references. It seems to me that a number of documents are referenced in a normative way. For example, RFC3261, RFC3486, RFC3608, and draft.ietf-sipping-v6-transition.
      Section 4
      I'm not sure that you have the balance of RFC 2119 language right...
      "2) A proxy must implement special "multi-homed" logic. During the"
      "Therefore this document recommends not rewriting the Record-Route."
      but...
      "Instead, proxies SHOULD use the double Record-Route approach. This"
      Section 9
      "It MAY have an impact on services involving topology hiding or privacy, as specified in [RFC3323]."
      It is not appropriate to use RFC 2119 language in this case!
      I don't find the security section very thorough. It doesn't indicate how to protect against the trheat indicated, and it doesn't comment on the risks introduced by modifying or inserting false record-route information.
    3. Cullen Jennings: Discuss [2009-07-15]: I think this should be a PS (and not update 3261).
      There is something wrong with the quote text
      "It is to notice that [I-D.ietf-sip-sips] has weakened the sip/sips URI rewriting requirement in the Record-Route header by removing this second paragraph."
      This is not part of 3261.
      I'd like to see the draft have clear guidance on transport=tls and what to do when switching from TLS transport to non TLS transport.
    4. Tim Polk: Discuss [2009-07-14]: Shouldn't this document update 3261?
      Comment [2009-07-14]:
      Section 3.2, second quote from RFC 3261: the third paragraph is not part of the quotation, but the indentation implies that it is part of the quoted text. Suggest reducing the indentation to match other non-quoted text.

    Telechat:

  5. Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates (Proposed Standard)
    draft-ietf-sip-eku-05
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Ron Bonica: Discuss [2009-07-15]: Supporting Bernard Aboba's comments cited by Alexey
    2. Adrian Farrel: Comment [2009-07-16]:
      The text says...
      "Consider the SIP RFC 3261 [2] trapezoid shown in Figure 1."
      ...but the figure does not show a trapezoid. I guess there is an implied dotted line between alice and bob?
      No doubt Appendix A needs the BSD license applied.
    3. Russ Housley: Comment [2009-07-13]:
      The OID needed for the ASN.1 module identifier is:
      id-mod-sip-domain-extns2007 OBJECT IDENTIFIER ::= { id-mod 62 }
      I see no reason to include id-pe and id-aca in the module.
    4. Cullen Jennings: Discuss [2009-06-24]: IANA says:
      "We understand that draft-ietf-sip-eku-05.txt doesn't ask for any IANA actions. But Russ, should we have a pointer to the pkix registry in http://www.iana.org/assignments/smi-numbers?"
    5. Alexey Melnikov: Discuss [2009-07-15]: This is a DISCUSS DISCUSS and I intend to clear it after/during the IESG telechat. Bernard Aboba <Bernard_Aboba@hotmail.com> did an O&M Area review of the document which said:
      "Previous EKU extensions (such as [RFC 4334]) have not been widely deployed, due to the additional operational complexity they would have introduced, and the limited benefits."
      Given this, and the potential interoperability impact of this document, the Experimental classification would probably be more appropriate.
    6. Tim Polk: Discuss [2009-07-14]: This is a discuss-discuss; I intend to clear on the call (if not before) after discussion of this relatively minor point.
      The id-kp-serverAuth and id-kp-clientAuth EKU values seem an odd fit for SIP EKU, but this specification permits acceptance as a matter of local policy. Is there an installed base that is already accepting these OIDs to authenticate SIP proxies?
    7. Dan Romascanu: Discuss [2009-07-15]: This DISCUSS and COMMENT is partly based on the OPS-DIR review performed by Bernard Aboba.
      In situations where there are pre-existing certificates without the EKU extensions, this specification could result in interoperability problems if the "local policy" is not carefully implemented. One concern is that the language on "local policy" could be used by implementers to justify refusing to support existing certificate formats.
      I do not think that the document adequately addresses how to manage the transition. For example, during an interim period, it would be necessary for implementations to support both legacy certificates as well as certificates with the new extensions. At some point, once the legacy certificates have expired, "local policy" could be changed to require only certificates with extensions.
      The document is missing an operational considerations section and and there seems to be quite a lot of operational implications. For example it does not discuss what kinds of "local policy" are appropriate in various situations or how the "local policy" can be configured or managed. It does not discuss how certificate interoperability issues can be dealt with, or how operational problems could be diagnosed. Some additional discussion in this area would be needed.
      Comment [2009-07-15]:
      1. I support the DISCUSS by Alexey about possibly approving this document at Experimental only, taking into accound that EKU did not enjoy wide deployment yet
      2. Section 3
      "A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-SIPdomain attribute in the Extended Key Usage extension value (see Section 3.1)."
      Question: What is the definition of "SIP domain identity"? This is not included in the terminology section.
      3. Section 4
      "Section 7.1 of Domain Certificates in the Session Initiation Protoco [8] contains the steps for finding an identity (or a set of identities) in an X.509 certificate for SIP. In order to determine whether the usage of a certificate is restricted to serve as a SIP certificate only, implementations MUST perform the step given below as a part of the certificate validation:"
      Not sure how the first sentence relates to the rest of the paragraph. Is the intent to suggest that the process for finding the identity needs to be carried out in order to make the determination? If so, then [8] would be a normative reference.
      4. "If the certificate does not contain any EKU values (the Extended Key Usage extension does not exist), it is a matter of local policy whether or not to accept the certificate for use as a SIP certificate."
      There are a large number of existing certificates issued without these EKUs. In situations in which these existing certificates are expected, leaving their acceptance up to "local policy" would seem likely to create an interoperability problem.
      5. " If the certificate contains the id-kp-sipDomain EKU extension, then implementations MUST consider the certificate acceptable for use as a SIP certificate."
      I presume that this means "implementations of this specification", correct? Pre-existing implementations don't know about these EKU extensions, and so will make their determination based on other factors.
      6. "If EKU extension exists but does not contain any of the id-kp-sipDomain, id-kp-anyExtendedKeyUsage, id-kp-serverAuth, or id-kp-clientAuth EKU values, then implementations MUST NOT consider the certificate as acceptable for use as a SIP certificate."
      Here I think you're referring to pre-existing implementations as well, correct?

    Telechat:

  6. Redirect Mechanism for IKEv2 (Proposed Standard)
    draft-ietf-ipsecme-ikev2-redirect-11
    Token: Tim Polk
    Extracted from Balloting:
    1. Adrian Farrel: Discuss [2009-07-16]: This is a fine document and only needs a few tweaks to address these issues and possibly the comments I have also raised.
      I don't see any description of prevention of redirect bouncing except a count described in non-2119 language in the security considerations. I think you need...
      1. A VPN gateway MUST NOT redirect to the VPN gateway indicated in the Redirected-From field.
      2. A client MUST track redirects and SHOULD give up if it is ever redirected back to a VPN gateway that has already performed a redirect.
      This certainly applies to IKE_SA_INIT and IKE_AUTH redirects, but I am not sure about redirect of an active session. Presumably this could legitimately be moved back and forth between gateways. You would need a different mechanisms (including a timer?) to prevent thrashing.
      In the anycast case you need to state whether the Redirected-From should indicate the anycase address or the VPN gateway doing the redirect. In either case, there are some subtle interactions with the redirect bounce prevention mechanisms.
      Comment [2009-07-16]:
      VPN should be expanded on first use in the Abstract and the main text.
      IPsec should be referenced on its first use.
      Abstract says:
      "Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent."
      Would prefer this to be reworded since this I-D creates such a mechanism. How about...
      "This document defines an IKEv2 mechanism that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent."
      Section 3
      "The gateway MUST keep track of those clients that indicated support for the redirect mechanism and those that didn't."
      Surely it only has to keep track for those clients for which it may want to perform a redirect?
      Rename section 5 to: "Redirect during an active session" since *all* redirects are gateway initiated.
      Bit numbers on the figures are out of alignment
    2. Cullen Jennings: (blank)

    Telechat:

  7. Metering and marking behaviour of PCN-nodes (Proposed Standard)
    draft-ietf-pcn-marking-behaviour-04
    Token: lars.eggert%40nokia.com; Note: Document Shepherd: Steven Blake (sblake@petri-meat.com)
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-07-15]: Very minor suggestion for improving readability - add a citation or two to docs providing background on PCN to the Introduction section.
    2. Adrian Farrel: Discuss [2009-07-15]:
      Section 1
      It may seem petty, but I think it is important for the status of this document...
      "This document standardises the two metering and marking behaviours of"
      s/standardises/describes/
      An RFC Editor note will suffice.
      I am supprised that all references are informative and none normative. At the very least, RFC 2119 is normative. I suspect a number of the others are also mandatory for correct interpretation of this document.
      Comment [2009-07-15]: RED is used without expansion
    3. Alexey Melnikov: Comment [2009-07-11]: This document has no Normative references? What about RFC 2119?
    4. Tim Polk: Discuss [2009-07-14]:
      I think the Security Considerations are inconsistent with respect to the threat from PCN-interior-nodes. The first paragraph ends of section 4 ends with:
      "More subtly, the rogue PCN-interior-node could perform these attacks selectively on particular flows, or it could PCN-mark the correct fraction overall but carefully choose which flows it marked."
      The next paragraph begins with:
      Note that PCN-interior-nodes are not flow-aware. This prevents some security attacks where an attacker targets specific flows in the data plane -- for instance, for DoS or eavesdropping."
      Perhaps I don't understand the meaning of "flow-aware", but it seems odd to state that a rogue PCN-interior-node might "carefully choose which flows it marked" and then state the node isn't flow-aware.
    5. Magnus Westerlund: Discuss [2009-07-16]:
      Section 1.1 and 2.1:
      Isn't the definition of non-PCN-competing traffic insufficient. Wouldn't a best effort class traffic compete with a EF class PCN marked in the sense that EF class gets preferential treatment but still share a common underlying resource. Isn't the traffic class a fundamental concept to discuss here. It is not clear to me if the Competing-non-PCN-packet must be in the same traffic class or not.
      Section 2.3:
      What is the unit for the rate? And what is the behavior of the filling of the token bucket?
      This applies to the excessive traffic meter also.
      Section 2.4:
      Behavior when bucket is empty or negative is poorly defined. If the token becomes empty, the drainage of excessive tokens, are they simply discarded. Or are they stored to later consume tokens as the bucket is filled?
      To me it appears that the difference between the packet size independent is that in this case it allows the bucket to have dept for all tokens forwarded. And the fill rate first tries to pay of the debt before becoming positive. Any additional metering of packets simply increases the debt if it hasn't managed to become a positive value. While the first meter will discard the debt for each packet, simply mark that packet. Is that understanding correct?
      For example the following sentence is not clear if one shall act according to it prior to deducting the packets worth of token or not:
      "If the token bucket is negative (F_etm < 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked."
      I think this needs to be clarified.
      Section 2.5:
      As this draft is discussing the markings by PCN on an abstract level shouldn't it discuss the markings that combine ECN and PCN also as a set of markings that MAY need to be supported?

    Telechat:

  8. Load Balancing for Mesh Softwires (Proposed Standard)
    draft-ietf-softwire-lb-03
    IPR: Cisco's Statement of IPR related to draft-ietf-softwire-lb-03
    Token: Ralph Droms; Dave Ward (dward@cisco.com) is the document shepherd
    Extracted from Balloting:
    1. Russ Housley: Discuss [2009-07-13]: The discussion of the Gen-ART Review by Avshalom Houri lead to a rewrite of the security considerations section. The document does not reflect this update, and there is not an RFC Editor note in the tracker to update the text.
    2. Tim Polk: Comment [2009-07-14]: I support Russ's discuss - the security considerations are technically correct, but should be expanded a bit to assist the reader...

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Extensible Provisioning Protocol (EPP) (Standard)
    draft-hollenbeck-rfc4930bis-02
    Token: alexey.melnikov%40isode.com; Note: Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd
    Extracted from Balloting:
    1. Dan Romascanu: Discuss [2009-07-16]: Is there an implementation and interoperability report or some other document that speaks about the 'significant implementation and successful operational experience' has was achieved and about the 'significant benefit to the Internet community' brought by this protocol that justify the elevation to the Internet Standard level? I could not find this information in the document or in the PROTO write-up.
    2. Robert Sparks: Discuss [2009-07-15]: I expect to clear this discuss after a quick discussion.
      Would it be easy to pull together an artifact somewhere capturing a sense of growth of the implementation base and operational experience beyond what's in the original implementation report?

    Telechat:

  2. Extensible Provisioning Protocol (EPP) Domain Name Mapping (Standard)
    draft-hollenbeck-rfc4931bis-01
    Token: Alexey Melnikov; Note: Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd. See IDtracker comment for draft-hollenbeck-rfc4930bis for the full write-up for all 5 draft-hollenbeck-rfc493*bis documents
    Extracted from Balloting:
    1. (none)

    Telechat:

  3. Extensible Provisioning Protocol (EPP) Host Mapping (Standard)
    draft-hollenbeck-rfc4932bis-01
    Token: Alexey Melnikov; Note: Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd. See IDtracker comment for draft-hollenbeck-rfc4930bis for the full write-up for all 5 draft-hollenbeck-rfc493*bis documents
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-07-13]: Please sonsider rewording the one sentence flagged in the Gen-ART Review by Avshalom Houri for clarity:
      Line 151: an internal host is subordinate relates to a domain within the

    Telechat:

  4. Extensible Provisioning Protocol (EPP) Contact Mapping (Standard)
    draft-hollenbeck-rfc4933bis-02
    Token: Alexey Melnikov; Note: Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd. See IDtracker comment for draft-hollenbeck-rfc4930bis for the full write-up for all 5 draft-hollenbeck-rfc493*bis documents
    Extracted from Balloting:
    1. (none)

    Telechat:

  5. Extensible Provisioning Protocol (EPP) Transport over TCP (Standard)
    draft-hollenbeck-rfc4934bis-01
    Token: Alexey Melnikov; Note: Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd. See IDtracker comment for draft-hollenbeck-rfc4930bis for the full write-up for all 5 draft-hollenbeck-rfc493*bis documents
    Extracted from Balloting:
    1. Tim Polk: Discuss [2009-07-16]: This specification requires mutually authenticated TLS, but the specification only requires the client to match the server certificate against the "reference identity". Is there a reason similar requirements were not specified for server authentication of the client certificate? There may be a need for two sets of requirements: one for user-based clients and another for automated clients.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks (Informational)
    draft-ietf-ancp-framework-10
    IPR: Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp-framework-08 and draft-ietf-ancp-protocol-05
    Token: Ralph Droms; Note: Wojciech Dec (wdec@cisco.com) is the document shepherd
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-22]:
      * Editorial nit - it's worth a comment as it's either a pretty noticeable typo or I'm pretty confused.
      In Figure 1, should the label "Aggreg. Node" actually read "Aggreg. Network"?
      * In section 4.1, second bullet list: the sentence
      "This MUST allow to retrieve statistics and alarms (e.g. via SNMP) about the"
      is missing some words
      * RFC 2119 terminology is not uniformly capitalized; for example, in section 4.2:
      o The ANCP MUST support providing multicast conditional access information to Access Ports on an Access Node, using Black, Grey and White lists.
      o The ANCP MUST support binding a particular Black, Grey and White List to a given Access Port.
      o Upon receiving a join to a multicast flow which matches the Grey List the ANCP MUST allow the AN to query the NAS to request an admission decision for replicating that multicast flow to a particular Access Port.
      o The ANCP MUST allow the NAS to send an admission decision to the AN indicating whether or not a multicast flow may be replicated to a particular Access Port.
      o The ANCP must allow the NAS to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port and where needed whether or not the Access Node is authorized to perform Admission Control itself (i.e. whether or not AN Bandwidth Delegation applies).
      o In case of Admission Control without AN Bandwidth Delegation, the ANCP must allow the NAS to reply to a query from the AN indicating whether or not a multicast flow may be replicated to a particular Access Port.
      o In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port for multicast services only.
      * Section 4.7.8: expand acronym "LAC"
    2. Adrian Farrel: Comment [2009-07-16]: Nits
      Abstract and Section 1
      s/OSS systems/Operational Support Systems (OSSes)./
      Section 1
      Expand ONU, NAS, and OSS on first use.
      Section 1.2
      Expand RS on first use.
      Section 2.1
      Expand CPE and HGW somewhere near the figure.
      ITU-T G.993.2 should be included as a reference.
    3. Russ Housley: Discuss [2009-07-13]:
      Please consider the three reviews that all arrived on 29 June 2009:
      - Gen-ART review by Ben Campbell;
      - TSV Directorate review by Scott Brader; and
      - Security Directorate review by Pat Cain.
      Each of the reviews offers important opporunitites for improvement. Taken together, the document should probably be updated prior to approval.
    4. Tim Polk: Discuss [2009-07-16]: This is a trivial discuss but -- the edit proposed by Pat Cain in his secdir review and agreed to by the authors does not appear in this draft or an RFC Editor Note. As Pat noted, draft-ietf-ancp-security-threats also develops a number of security requirements that are not reproduced in this framework document. The security considerations text should alert readers to their inclusion in draft-ietf-ancp-security-threats.
    5. Magnus Westerlund: Comment [2009-07-16]: Support Russ discuss that the doc needs to be revised prior to approval.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. The Remote Framebuffer Protocol (Informational)
    draft-levine-rfb-01
    Token: Cullen Jennings; Note: Port 5500 should not be used and is only mentioned for historical context
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-07-15]: Section 6 mentions that several versions of RFB have been published. Would it be possible to add references to the docs in which those versions have been published? Or is it the intention of this doc to obsolete those earlier docs?
    2. Adrian Farrel: Discuss [2009-07-16]: Two simple Discusses that can be cleared with minor text or after an email exchange.
      Section 1 notes...
      "fairly good interoperability"
      Would it be worth explaining the interoperability issues. Are they a reuslt of bugs, misunderstandings of the specification, or options? Does the documentation of RFB in this way mean that some implementations will be automatically made non-conformant?
      The note in the tracker says...
      "Port 5500 should not be used and is only mentioned for historical context."
      This is fine, but surely the document should be updated accordingly.
    3. Russ Housley: Discuss [2009-07-13]: Please place normative and informational references in different subsections.
    4. Alexey Melnikov: Discuss [2009-07-11]: I am very glad that this protocol is going to be documented in an RFC. I have a couple of nits which I want to discuss before voting Yes on this document and I am perfectly fine with them being addressed (if I am right) as RFC Editor notes:
      1). In Section 7.7.5:
      You lost me here:
      "TRLE makes use of a new type CPIXEL (compressed pixel). This is the same as a PIXEL for the agreed pixel format, except where true-color-flag is non-zero, bits-per-pixel is 32, depth is 24 or less and all of the bits making up the red, green and blue intensities fit in either the least significant 3 bytes or the most significant 3 bytes. In this case a CPIXEL is only 3 bytes long, and contains the least"
      What is "this" referring to here?
      "significant or the most significant 3 bytes as appropriate. bytesPerCPixel is the number of bytes in a CPIXEL."
      Is this paragraph just trying to say that each pixed is encoded as 3 bytes?
      Some example would be helpful here.
      2). In the same section:
      "Each tile begins with a subencoding type byte. The top bit of this byte is set if the tile has been run-length encoded, clear otherwise. The bottom seven bits indicate the size of the palette used: zero means no palette, one means that the tile is of a single color, and 2 to 127 indicate a palette of that size. The special values 129 and 127 indicate that the palette is to be reused from the previous tile,"
      First you say that the palette size can be 127, but then you say that 127 is a special value. I think you meant "2 to 126 indicate a palette of that size".
      Comment [2009-07-11]:
      I assume values of padding fields are ignored? Or do they have to contain all zeros?
      I don't expect you to do anything about the following comments. If a future version of this protocol is developed in IETF, I hope they can be addressed:
      7.5.6. ClientCutText
      "RFB provides limited support for synchronizing the "cut buffer" of selected text between client and server. This message tells the server that the client has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the newline character (hex 0a) alone. No carriage-return (hex 0d) is used. There is no way to transfer text outside the Latin-1 character set."
      :-(
      I am also hoping that a future version can integrate the SASL authentication framework (RFC 4422).
      And finally, language tags can be used for human readable text (RFC 4646).
    5. Tim Polk: Discuss [2009-07-16]: I believe that the security considerations section needs to be expanded. Readers need more guidance to determine when the standard security types might be acceptable. Some of the necessary information is implied in section 7.2.2:
      "This type of authentication is known to be cryptographically weak and is not intended for use on untrusted networks. Many implementations will want to use stronger security, such as running the session over an encrypted channel provided by IPSEC [RFC4301] or SSH [RFC4254]."
      It would be interesting to hear when the security type "none" is considered appropriate. I tend to believe that "none" is inappropriate and should not be used unless security is being handled unless security is being handled by IPsec, SSH, etc...
    6. Robert Sparks: Discuss [2009-07-15]: Would it make sense to move the encoding and security type ID regiestry to IANA?
      Comment [2009-07-15]: It would be good to explicitly call out the origin and sense of the coordinate system being used.

    Telechat:

  2. Suite B Certificate and Certificate Revocation List (CRL) Profile (Informational)
    draft-solinas-suiteb-cert-profile-04
    Token: Tim Polk
    Extracted from Balloting:
    1. Alexey Melnikov: Discuss [2009-07-12]: A minor issue:
      It seems that both [RFC5480] and [sha2-dsa-ecdsa] must be Normative References.

    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)

1325 EDT break

1328 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. Mobility for IPv4 (mip4)
    Token: Jari

    Telechat:

4.2.2 Proposed for Approval

  1. DNS Extensions (dnsext)
    Token: Ralph

    Telechat:

5. IAB News We can use

  1. Russ: three things, liaison from ITP regarding CODEC (stepping on toes); update to uncoordinated-harmful, -01 posted; nomination period re RFCed extended to August 8

6. Management Issues

  1. IESG Note for draft-floyd-tcpm-ackcc (Sandy Ginoza)

    Telechat:

  2. Large ISPs asking about additional private address space [IANA #252131] (Michelle Cotton)

    Telechat:

  3. PA-TNC (Tim)

    Telechat:

7. Agenda Working Group News

1357 EDT Adjourned