IESG Narrative Minutes

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

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

Corrections from: Russ

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. RSVP Extensions for Path-Triggered RSVP Receiver Proxy (Proposed Standard)
    draft-ietf-tsvwg-rsvp-proxy-proto-09
    IPR: Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-proxy-proto
    Token: Magnus Westerlund Note: Please read the informational document draft-ietf-tsvwg-rsvp-proxy-approaches before this one!
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-05-19]: I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.
      For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.
      Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.
      The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.
    2. Ross Callon: Comment [2009-05-21]: I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network).
      I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail.
      I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.
    3. Ralph Droms: Comment [2009-05-19]: Is the problem described in this text from section 3 a new problem introduced by RSVP receiver proxies:
      "While the sender could infer reservation failure from the fact that it has not received a Resv message after a certain time, there are clear benefits in ensuring that the sender gets a prompt, explicit notification in case of reservation failure..."
    4. Adrian Farrel: Comment [2009-04-29]: Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor misses them.
      ...I am a little bothered by the use of "protected by an RSVP reservation" throughout the document. This is not the use of "protection" that I am familiar with. Perhaps "guaranteed" or "enabled"?
      Figure 4: The key does not explain NotifyU
    5. Cullen Jennings: Discuss [2009-05-21]: I have placed all my issues for this spec into the discuss for proxy-approaches as it seemed better to have them in one place. Once we resolve theses, we can figure out what to do here. I would expect for important things like deployment applicability, for theses to occur in this specification and not just by reference to an informational document.
    6. Tim Polk: Discuss [2009-05-20]: The specification implies that use of these extensions is restricted to Receiver Proxies, but as I understand it, the sender has no way to determine whether they are performing end-to-end RSVP or communicating with a proxy. If a Regular RSVP Receiver implemented sender notification, what are the consequences (if any)?
    7. Robert Sparks: Comment [2009-05-19]: The document currently doesn't discuss how a proxy knows to act as a proxy. It appears that if a proxy as defined in this document is placed in front of a RSVP capable endpoint, that endpoint will cease to be allowed to participate in RSVP with no indication of why. Was that the intent, and if so, shouldn't this be explained in the document?

    Telechat:

  2. DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal (Proposed Standard)
    draft-ietf-dccp-simul-open-08
    Token: Lars Eggert
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2009-05-15]: One editorial nit: there are two instances of "LISTEN'" that probably should be "LISTEN1" instead.
    2. Adrian Farrel: Comment [2009-05-21]:
      Section 2.2.1
      I believe that the final paragraph ("The remaining fields, including...") should include a full list of the fields. Further, the note should be placed before the text that states the specific values to be assigned to those fields.
      It might be nice to discuss the X field just once.
      It would be helpful to place the RFC Editor note immediately adjacent to the paragraph that deines the setting of the Type field.
      Figure 2: The figure does not make it clear whether the DCCP-Listen should be sent a third time on time-out from Invited state. The text says "at most 2 retransmissions" so the figure appears to be wrong. It should say "3rd timeout".
    3. Alexey Melnikov: Comment [2009-05-15]:
      2.2.2. Protocol Method for DCCP Server Endpoints
      typo
      2.2.3.1. Optional generation of Triggered Requests
      typo
    4. Tim Polk: Comment [2009-05-21]:
      Section 2.2.2, Note under the Figure
      s/A server that responds a DCCP-Request/A server that receives a DCCP-Request/
      s/LISTEN1state/LISTEN1 state/
      s/LISTEN1states/LISTEN1 states/
      Section 4, Security Considerations, paragraph 4 has unbalanced parentheticals...
      s/SDP [RFC4566])/SDP [RFC4566]/

    Telechat:

  3. MPLS Generic Associated Channel (Proposed Standard)
    draft-ietf-mpls-tp-gach-gal-05
    Token: Adrian Farrel Note: This I-D was last called in MPLS and PWE3; It has been approved by the ITU-T; IANA comments have been answered satisfactorily; Loa Andersson (loa@pi.nu) is the document shepherd
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-05-20]: In the Gen-ART Review, Miguel Garcia points out that the following sentnece in the first paragraph of Section 3.1 cn be interpretted in more than one way:
      "The structure of ACH TLVs that MAY follow an ACH TLV Header is defined and described in the following sections."
      Rewording to add clarity is desirable.
    2. Alexey Melnikov: Comment [2009-05-21]: I assume all 16bit fields are in network byte order?

    Telechat:

2.1.2 Returning Items

  1. An Internet Attribute Certificate Profile for Authorization (Proposed Standard)
    draft-ietf-pkix-3281update-05
    Token: Tim Polk
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-04-20]: s/IPSec/IPsec/ x2
    2. Dan Romascanu: Discuss [2009-04-21]: If I understand well the current rules and the latest interpretation given by the Legal Counsel of the IETF, the code in Appendix B should include the (long version) copyright notice in "code" similarly to MIB modules and such.
    3. Robert Sparks: Comment [2009-04-20]: The diff between this and 3281 is pretty simple. The deletion of this sentence (near the end of page 32 of 3281 update) sticks out on casual inspection:
      "In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present."
      I wanted to shine the light on it to make sure its deletion was intentional.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. H.248/MEGACO Registration Procedures (BCP)
    draft-groves-megaco-pkgereg-03
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-05-21]: This document is fine overall, but there were two parts that I was unable to understand. Am I missing something obvious, or is there a mistake in the document:
      "3) The public package requester shall provide a reference to a document that describes the package, which should be public:
      "a) The document shall specify the version of the package that it describes.
      "b) If the document is public, it should be located on a public web server and should have a stable URL. The site should provide a mechanism to provide comments and appropriate responses should be returned.
      "c) If the document is not public, it must be made available for review by the IESG appointed Expert (without requiring an NDA) at the time of the application."
      I am not sure I understand how a "public package requester" can ask for a value to a non-public specification, even if the expert reviewer will be able to see it.
      "Note: The documenting text does not have to be publicly available at the time of the registration request, however the text shall be provided and available for review by the IESG appointed Expert at the time of application."
      I do not understand the difference between "at the time of the registration request" and "at the time of application".
      Also, how about s/documenting text/document/?
      Comment [2009-05-21]:
      "1. Binary ID (or serial number)"
      Do people really register these using the binary representation? Perhaps you mean numeric, not binary. On the wire the number may be binary, but the IANA registry, for instance, uses hexadecimal representation. (http://www.iana.org/assignments/megaco-h248)
    2. Russ Housley: Comment [2009-05-19]: From the Gen-ART Review by Pete McCann ...
      Section 4: typos
      Section 6.2: typo
      Section 6.3: s/(Specification required/and required specification/
    3. Alexey Melnikov: Discuss [2009-05-21]: 5.3. Error Code Registration Procedure
      "6) An error number shall not be redefined nor modified except by the organization or individual that originally defined it, or their successors or assigns."
      I would like to better understand what is meant by "redifinition or modification" of an error number?
      If this means that the error condition associated with an error is redefined, then surely this should result in another Expert review (to make sure that redifinition is a clarification, as opposed to assignment of a totally different meaning). If redefinition means changing of the error number, then again, this would require another Expert review.
      Comment [2009-05-21]: I think IANA registration templates for "Error Code Registration" (section 6.2) and "ServiceChange Reason Registration" (section 6.3) should also include the owner/contact information.
    4. Tim Polk: Comment [2009-05-21]: I support Alexey's Discuss.

    Telechat:

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets (Experimental)
    draft-ietf-tcpm-ecnsyn-09
    Token: Lars Eggert
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-05-21]: Excellent work. It was a pleasure to read this.
    2. Pasi Eronen: Discuss [2009-05-15]: I have reviewed draft-ietf-tcpm-ecnsyn-09. Overall, the document looks OK, but there are two things that should be fixed before the document is approved:
      The document does not have any normative references -- certainly at least RFC793 and RFC3168 should be normative? (perhaps some others, too)
      Since the document uses RFC 2119 key words, it should have a (normative) reference to RFC 2119.
    3. Tim Polk: Comment [2009-05-21]: Good document overall.
      This document might benefit from a description of the experiment(s) that should be run to see if deployment is beneficial. (Section 6 indicates that the answer will be different based on the specific environment).

    Telechat:

  2. DomainKeys Identified Mail (DKIM) Service Overview (Informational)
    draft-ietf-dkim-overview-11
    Token: Pasi Eronen
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-05-21]: In section 1.4.1 you have "(per Allman)". Presume this is a reference to RFC 4871 and so changning to "[RFC4871]" would be nice. but if it is a reference to something else, perhaps you could iclude it.
    2. Alexey Melnikov: Comment [2009-05-16]:
      1. Introduction
      typo
      1.2. Prior Work
      "There have been four previous IETF Internet Mail signature standards. Their goals have differed from those of DKIM. The first two are only of historical interest."
      Actually, I think the 2nd and the 3rd are of historical interest. I.e. OpenPGP is still in use.
      "PEM eventually transformed into MIME Object Security Services (MOSS) in 1995. [RFC1848] [RFC1991]"
      RFC 1991 is "PGP Message Exchange Formats". Is it the correct reference here?
      2.2. Enabling Trust Assessments
      typo
      3.1.1. Use Domain-level granularity for assurance
      typo
      3.1.4. Distinguish the core authentication mechanism from its derivative uses
      typo
    3. Tim Polk: Comment [2009-05-21]: In Figure 1, the flow from the "Assessments" box is non-deterministic; it appears the next step could be "Check Signing Practices" or "Message Filtering Engine". The supporting text in Section 5.5 did not clarify the situation.
      I would suggest labeling the diagram or adding explanatory text in 5.5.

    Telechat:

  3. RSVP Proxy Approaches (Informational)
    draft-ietf-tsvwg-rsvp-proxy-approaches-07
    IPR: Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt
    Token: Name Magnus Westerlund: Note: Read this before the Protocol document; Was deferred by Cullen Jennings on 2009-05-05
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-05-21]: I am not against publishing these specifications (and I guess even the authors see them as necessary evil in comparison to the end-to-end RSVP model). However, I think the documents should describe more clearly their implications and limitations. A Surgeon General's Warning if you will.
      I'll note that I am not an RSVP expert. I may have missed something. In that case, please educate me and I'll clear this Discuss.
      In particular, Section 4.1 says:
      "In order to build the Resv message, the RSVP Receiver Proxy can take into account information received in the Path message. For example, the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv message which mirrors the SENDER_TSPEC object in the received Path message."
      RSVP has separate flow reservations for the two directions, and just copying the flow spec from one direction to another is a severely limited approach. Or perhaps even a potentially harmful approach. For instance, in any streaming or IPTV situation this approach would clearly lead to problems. One could ask how well the network works (a) with the proxy QoS reservations or (b) without any reservations. The ability to make the reservations allows bandwidth to be reserved, and increases the likelihood of, say, successful video transmission. However, the guessing involved in the mirroring process leads to incorrect reservations...
      The application triggered mechanisms have a better chance of a successful outcome, but they imply fairly severe involvement in the application signaling process, such as the introduction of a b2bua. What's the likelihood of a b2bua on the signaling path disrupting your intended communication setup? I'd claim its a non-zero probability...
      I would suggest that Section 4.1 needs to include additional text to document the problems associated with mirroring. Also, the introduction should provide stronger guidance on the overall benefits vs. disadvantages associated with the proxies, and suggest that the proxies only be setup for very specific networks, applications, and flows to specific destinations.
    2. Ron Bonica: Comment [2009-05-19]: I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.
      For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.
      Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.
      The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.
    3. Ross Callon: Comment [2009-05-21]: I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network).
      I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail.
      I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.
    4. Ralph Droms: Comment [2009-05-21]: In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater for notification of the sender of the reservation failure." It's not clear to me why the sender needs to be notified of reservation failure. Is this addressing a problem with RSVP generally or just RSVP Receiver Proxy? I speculate that the problem here may be that the Proxy receives the ResvErr, so neither the application receiver nor the sender is explicitly notified of the reservation failure; do I have that right? Would someone more familiar with RSVP than I am be able to deduce the reason for sender notification? I'm happy to be educated as I'm not well-versed in RSVP.
      Nit: "cater for" might read better as "cater to" or "provide for"
    5. Adrian Farrel: Comment [2009-04-29]: Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor misses them.
      I am surprised that all of your references are Informative. Surely some of these are prerequisites for understanding your work?
    6. Cullen Jennings: Discuss [2009-05-21]: Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.
      For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy.
      How does one migrate out proxy RSVP to end to end RSVP?
      How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services.
      For something like triggered approach, when does the reservation get town down?
      The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS.
      The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify.
      ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use.
      Has the working group considered if there are ways to achieve this that are not IPR encumbered?
      The example in A.3 seems really confused about how SBC work.
      As I am sure the authors of this draft are aware, the example in A.5 was something the SIP WG had more than one strong hum on this was not an appropriate use of SIP.
    7. Alexey Melnikov: Comment [2009-05-03]: 4.3. Inspection-Triggered Proxy
      "Note however, that in case of reservation failure, the inspection-triggered RSVP Proxy does not have a direct mechanism for notifying the application..."
      The first use of the DSCP acronym should be expanded.
      I am also agreeing with Adrian's comment, I was wondering about this myself.
    8. Tim Polk: Discuss [2009-05-05]: Two issues: number one is actionable, the second is a discuss-discuss...
      Issue #1: The security considerations do a nice job highlighting the issues introduced by proxies, but more detail is needed with respect to RSVP proxies that operate under control of another entity (Para 4). These models introduce new security requirements for communication between the proxy and the controlling entity that are outside the scope of RSVP or this document. Specifically, these models introduce authentication and confidentiality requirements to protect against a variety of attacks. The current text indicates the controlling entity needs to be trusted, which is also true, but is insufficient.
      Issue #2: (Section 1, Introduction) What are the consequences of violating the topological constraints and having two Receiver Proxies on path? It seems that RSVP would not be used to its fullest, and the resource reservation would cover less of the path than it could, but this seems to be sub-optimal rather than broken.
      I also wonder whether this merits discussion in the security considerations... perhaps that will become clear as we discuss the consequences of violating the topological constraints.
      Comment [2009-05-05]: section 1:
      "presents several fundamental RSVP proxy approaches insisting on how ..."
      I don't think "insisting" is the right word here!
      section 4.4:
      s/cortresponding/corresponding/
      s/implicitely/implicitly/
    9. Dan Romascanu:Comment [2009-05-21]:In Section 4.5:
      "Candidate protocols for realizing such interface include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the Extensible Markup Language (XML) and DIAMETER ([RFC3588])."
      SNMP is seldom used for configuration purposes over the Internet in real life. COPS-PR has very little reported deployment if at all. XML is manguage to present information and not a protocol.
      I suggest to take out XML, and to consider whether SNMP and COPS-PR should be left in the text. On the other hand I believe that it would be appropriate to mention here NETCONF (RFC 4741) which is a protocol that uses XML-encoding for performing configuration management operations on network devices.
    10. Robert Sparks: Comment [2009-05-17]: Agree with Tim's concern #2 (what happens when you unintentionally (or intentionally) end up with more than one proxy in a path?

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

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. The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Informational)
    draft-templin-seal-23
    Token: Jari Arkko: Note: Brought back to the agenda because of desired status change (now Inf)
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-05-20]: I will change my position to "No Objection" when the course of action suggested by Jari (in e-mail on 5/20) is carried out; draft-templin-seal-23.txt shows "Intended status: Informational":
      I have no problem with going ahead with this content and an Experimental RFC.
      (I did not have any problem with the original content either. You and the RFC Editor should work out which text actually goes out, you changed quite a bit and they had already done their editing.)
      RFC-Editor, Fred: I take it that we are back in the original plan, i.e., Experimental RFC and the IANA considerations as they were. If yes, I could just withdraw the draft from the new consideration of the IESG. Perhaps you want to send an e-mail to that effect to the IESG.
    2. Cullen Jennings: Discuss [2009-05-21]: On the IESG call, I would like to talk about if, given the IANA considerations, we need to add more the IESG note about the deployability of this.

    Telechat:

1224 EDT break

1229 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. Yet Another Mail (yam)
    Token: Alexey

    Telechat:

  2. Extensible Messaging and Presence Protocol (xmpp)
    Token: Cullen

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. Dave: no update, nothing of specific interest from Amsterdam meeting
  2. Russ: status of "harmful" draft, got comments from Malcolm, will forward to authors

6. Management Issues

  1. Ballot Procedures (Russ Housley)

    Telechat:

  2. Revision 1.9 for ID-Checklist.html (Russ Housley)

    Telechat:

  3. Shepherd names in agendas (Jari Arkko)

    Telechat:

  4. IESG Requirements to NomCom (Russ Housley)

    Telechat:

  5. Legal provisions relating to IETF documents (Russ)

    Telechat:

7. Agenda Working Group News

1346 EDT Adjourned