IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2008-05-08.

Narrative scribe: John Leslie

Corrections from Pasi, Jari

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. The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry (Proposed Standard)
    draft-ietf-iptel-tel-reg-05.txt
    Token: Jon Peterson Note: Jonathan Rosenberg is Proto Shepherd
    Discuss:
    1. Lars Eggert:
      Discuss [2008-05-08]:
      Section 3., paragraph 3: RFCs defining tel URI parameters or parameter values MUST register them with IANA as described below.
      Discuss-discuss: By "below", I assume you mean the IANA Considerations section. But what about tel URI parameters that aren't specified via RFCs (the policy is "Specification Required, Designated Expert", right?) Don't those also need to follow those guidelines?
      Comment [2008-05-08]:
      Section 3., paragraph 1: The tel URI parameters and values for these parameters MUST be documented in a RFC or other permanent and readily available public specification in order to be registered by IANA.
      Section 4.2 defines the polocy as "Specification Required, Designated Expert" from RFC2434 - could you use that same term here?
      Section 4.2., paragraph 1: As per the terminology in [6] and actions accorded to such a role, the registration policy for tel URI parameters shall be "Specification Required, Designated Expert" (the former implicitly implies the latter.)
      Why does "Specification Required" imply "Designated Expert"? That's not the case IMO.
    2. Pasi Eronen: Comment [2008-05-05]:
      The distinction between URI parameters that accept a set of predefined values vs. parameters that can accept any value would benefit from some clarification. Originally, I thought "predefined values" meant an enumeration (like "isub-encoding"), but later in the document, things like domain names, URIs, or strings of digits are also counted as "set of predefined values".
      Also, apparently there are currently no parameters in the "can accept any value" category -- so perhaps instead of talking about "predefined values", we could just classify parameters as "has a value" vs. "does not have a value"?
      The document probably should have "Updates: RFC 3966" on cover page since it changes the procedures defined in RFC 3966 (which says that "New mandatory parameters must be described in a standards-track RFC, but an informational RFC is sufficient for optional parameters.")
      Should the parameters used in obsolete RFC 2806 be marked as "reserved" in this registry? ('tsp' and 'postd')
    3. Chris Newman:Comment [2008-05-05]:
      Who is proposed as the designated expert for this registry?
      I strongly concur with all of Pasi's comments and recommend the authors consider them seriously. As a suggestion for clarity: instead of a yes/no for "predefined value", have a three-state "value-type" column that says one of: no-value, constrained, unconstrained. BTW, it appears there are no "unconstrained" parameters defined -- if that's likely to continue in the future, perhaps it's simpler to just omit the column altogether.

    Telechat:

  2. OSPF for IPv6 (Proposed Standard)
    draft-ietf-ospf-ospfv3-update-21.txt
    Token: David Ward
    Discuss:
    1. Ron Bonica:Discuss [2008-05-07]: This is more a question that an DISCUSS.
      Reading Appendix E, I conclude that implementations built according to this spec will be interoperable with implementations that are strictly compliant with RFC 2740. Do I have that right?
      If so, you might want to add some text saying that up front. Especially if you intend to remove Appendix E before publication.
      I am a little concerned about the following bullet from Appendix E:
      Correct field alignment in packet and LSA figures in Appendix A.
      If the field allignment were truly different between this document and 2740, wouldn't that introduce an interoperability problem? However, I stared at the figures in the two documents and couldn't see the difference. What does this bullet really mean?
    2. Lars Eggert:
      Discuss [2008-05-08]:
      Section 2.5., paragraph 3: On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets.
      Discuss-discuss: Why are virtual links being treated differently? They should have link-local addresses, too.
      Comment [2008-05-08]:
      Section 3.2.2., paragraph 8: The standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Appendix A.3.1).
      It isn't the IPv6 checksum that's being verified, because IPv6 has no checksum. It's the *OSPFv3* checksum that's being verified.
    3. Tim Polk: Discuss [2008-05-08]:
      This is a discuss discuss:
      RFC 2740 included the following text in its security considerations: Most OSPF implementations will be running on systems that support multiple protocols, many of them having independent security assumptions and domains. When IPSEC is used to protect OSPF packets, it is important for the implementation to check the IPSEC SA, and local SA database to make sure that the packet originates from a source THAT IS TRUSTED FOR OSPF PURPOSES.
      This text does not appear in either RFC 4552’s or ospfv3-update's security considerations. I was wondering why this guidance is no longer appropriate. Has the basic assumption (OSPFv3 systems will support multiple protocols) changed?
    4. Dan Romascanu: Discuss [2008-05-07]:
      There is no information on manageability considerations. At a minimum I would expect the document to mention that new objects need to be added in the management model leading to the OSPF MIB needs to be extended and to point as Informational Reference to http://www.ietf.org/internet-drafts/draft-ietf-ospf- ospfv3-mib-12.txt

    Telechat:

  3. Instant Message Disposition Notification (Proposed Standard)
    draft-ietf-simple-imdn-07.txt
    Token: Jon Peterson
    Discuss:
    1. Lars Eggert: Comment [2008-05-08]:
      Section 5.3., paragraph 2: In addition to text, some IMs may contain audio, video, and still images. Therefore, the state "read" includes playing the audio or video file to the user.
      Does it indicate the start of playback, or when playback has concluded? (Probably the former, but it might be good to be explicit in the text.)
      Section 5.3., paragraph 3: Since there is no positive acknowledgement from the user, one cannot determine _a priori_ the user actually read the IM. Thus, one cannot use the protocol described here as a non-repudiation service.
      That restriction - that getting a "read" IMDN doesn't actually mean that the recipient is guaranteed to have read the IM - seems important enough to describe more prominently, e.g., in the introduction. "Read" is maybe also a bit inaccurate, maybe "rendered" would be a better term, i.e., the IM has been rendered to the user, which is about asmuch as a program can guarantee it did. It's probably too late to make this wording change, but an explanation can still be added. (Nit: I don't understand what "a priori" is supposed to express in this sentence.)
      Section 7.1.1.1., paragraph 1: The Message-ID field is populated with a value that is unique with at least 32 bits of randomness.
      Nit: It's not unique, it's _statistically_ unique.
      Section 7.1.3., paragraph 2: Once an IM Sender sends an IM containing an IMDN request, it MAY preserve the IM context, principally the Message-ID, and other user-identifiable information such as the IM subject or content, and dateand time it was sent.
      Isn't a MAY a bit weak? Requesting IMDNs when I'm not going to be able to correlate them to specific sent messages seems to be pretty pointless.
      Section 12.1.1., paragraph 4: An IM Recipient can ignore such request if the IM Sender is anonymous.
      Nit: s/can/MAY/
      Section 13., paragraph 1: MSRP already provides a built-in mechanism to supply positive and negative delivery reports.
      Reference to MSRP missing.
      Section 14., paragraph 1: IMDNs provide a fine-grained view of the activity of the IM Recipient and thus deserves particularly careful confidentiality protection so that only the intended recipient of the IMDN will receive the IMDN. In most cases, the intended recipient of the IMDN is the IM Sender.
      When the IMDN recipient isn't the sender but instead the IMDN is addressed to multiple recipients, an amplification attack can be performed. Is this a new threat with IMDNs or is this already being discussed for the base IM transport?
    2. Chris Newman: Discuss [2008-05-06]:
      1. I could not find a response to Frank Ellermann's last call comments on "Wed, 16 Jan 2008 12:17:48 +0100" to the IETF mailing list. I do not consider it acceptable to simply ignore last call comments. Please cc me on any correspondence to Frank and the ietf list on this issue. Most of the issues he raised I consider discuss-level issues.
      2. The "read" status is misleading for the reasons 3798 describes. Why did you choose not to use "displayed" as defined in RFC 3798? Having semantically misleading statements in protocols is simply not good design and I'd like a justification for doing something different from the previous IETF draft standard in this area.
      3. This appears to combine DSN (RFC 3464) and MDN (RFC 3798) features into one protocol. As they are related and the primary reason for the specification split is historic, I think combining the features is a good thing. But there are semantic differences between the two protocols that are both useful and important. In particular, when a client requests a DSN it is guaranteed to get a response by RFC 3461, while responses to MDNs are optional. This is a very useful property although it is only possible if the "relayed" action from RFC 3464 is included in the model and generated in response to a request for delivery success status. Why did you choose not to provide this feature of DSNs? If the WG considered this and made a willful decision, I'm not going to insist on a change, but I at least want to understand why the IETF suite of standards will be inconsistent on such an important semantic.
      4. The decision to mix transitive routing information (IMDN-Record-Route, IMDN-Route) into the IMDN content itself is bad design, especially when that information is to be removed by intermediaries. That makes any sort of content based signature impossible, and such mechanisms are likely to become an important part of the necessary reputation systems as the volume of IM spam increases over time. Deliberately designing a signature-hostile format when it is so likely signatures will be critical to long term use of the protocol is something that will require extensive justification to convince me it's acceptable quality for an IETF standard.
      5. I could find no record of the IETF-types review in the IETF-types archives: http://www.alvestrand.no/pipermail/ietf-types/2007-February/thread.html Can someone please provide a copy of the review request as received from the ietf-types list expander? I want to make sure the message was actually distributed to the list and not lost in transit.
      6. RFC 3862 has an example message with the same subject in two different languages. How does the <subject> element handle this in the IMDN? Is a lang parameter included on the subject typically?
      7. When using a formal schema language, it is important to say in the specification how it relates normatively to this document and future extensions. Is the schema a normative definition of the current format? Is the schema a normative definition constraining all future extensions of the format? If the answer to the latter question is "yes", then I recommend you read chapter 12 of "Relax NG" by Eric van der Vlist and revise your Relax NG schema accordingly or you will be painting yourself in a box. Briefly: you should use the interleave pattern, I'm not sure your 'anyIMDI' is correct (see "anything" in the book) and if you put the addition of 'anyIMDI' in a separate define from the list of pre-defined elements that will simplify extending the schema. BTW, thanks for using RelaxNG as it's much simpler to read and review than W3C schema.
      8. Section 15.4 says both "Specification Required" and "IETF Standards track" (implying it's a "standards action" registry). What is the intended registry type?
      9. Have all the questions IANA asked been resolved?
      Note: I have deliberately not reviewed the security considerations section assuming the security directoriate and ADs have that covered.
    3. Tim Polk: Discuss [2008-05-06]:
      This is a process discuss. Eric Rescorla's secdir review (first posted February 8 and re-posted May 3) has never received a response.
      I consider the issues he raised on bounce/reflection threats and determining where to send the IMDN to be blocking. (Is the latter addressed in the last sentence of 12.1.3.1?) I also support avoiding the term non-repudiation unless it is defined in this document for this context.
    4. Magnus Westerlund: Discuss [2008-05-06]:
      Section 10:
      The ABNF is not complete and lacks references to some definitions. To my check even after including the ABNF from RFC 3862 the followings are undefined:
      COMMA
      SEMI
      generic-param
      Then there is a typo in the the rule:
      notify-req = ("negative-delivery" / "positive-delivery" / "processing" / "read" / Token) *(SEMI disp-notif-params)
      disp-notif-params is missing a "y"

    Telechat:

  4. PIM Bootstrap Router MIB (Proposed Standard)
    draft-ietf-pim-bsr-mib-05.txt
    Token: David Ward
    Discuss:

    Telechat:

  5. Layer 1 VPN Basic Mode (Proposed Standard)
    draft-ietf-l1vpn-basic-mode-04.txt
    Token: David Ward
    Discuss:
    1. Ron Bonica: Comment [2008-05-07]:
      In Section 1, you say:
      As with L3VPNs, there are protocol options to be made with auto-discovery.
      Did you mean protocol choices?
      In Setion 2, you say:
      Since the mechanisms specified in this document use GMPLS as the signaling mechanism, and since GMPLS applies to both SONET/SDH (TDM) and Lambda Switch Capable (LSC) interfaces, it results that L1VPN services include (but are not restricted) to Lambda Switch Capable or TDM-based equipment.
      Did you mean "it follows that"?
    2. Pasi Eronen: Discuss [2008-05-05]:
      As noted by Charlie Kaufman's and Sandy Murphy's SecDir reviews: the security considerations text is very sparse. At the very least, it should point to the (much more extensive) security considerations in RFC 4847 and draft-ietf-l1vpn-applicability-basic-mode-05, and briefly describe the existing security mechanisms (e.g. GMPLS/RSVP-TE) that can be used to address those concerns.
      In Section 4.1.2, something more should be said about the L1VPN globally unique identifiers, and in particular, who selects them and how global uniqueness is ensured (or is uniqueness within a service provider sufficient?), and how they're encoded (e.g. the format here doesn't match the VPN Identifier defined in RFC 2685).
      Section 4.1.2 needs a reference to a document that defines the CPI AFI values.
      Comment [2008-05-05]:
      The document could perhaps use a slightly longer explanation of how the PE, when it receives a RSVP message, determines which L1VPN it's associated with (since apparently the RSVP messages are not necessarily sent over the CE-PE link identified by CPI/PPI, and the L1VPN is not uniquely identified by CE-CC-Addr/PE-CC-Addr).
      Sandy's SecDir review also identified a number of places that would benefit from some clarification of the text, and provided editorial comments that should be taken into acccount.
    3. Russ Housley: Comment [2008-05-06]:
      There has been a dialogue between Sandy Murphy and Adrian Farrel that was begun by Sandy's SecDir Review. The Security Considerations in this document are very sparse, saying essentially that because the matching of customer channels to provider ports is assumed to be done correctly and out of band there are no security considerations. However, the dialogue between Sandy and Adrian shows that there is actually more to say. I support the DISCUSS position that Pasi has entered ...
    4. Tim Polk: Comment [2008-05-07]:
      Note that I support Pasi's discuss wrt security considerations.
      One nit:
      s 4.1, 1st sentence
      s/there/their/

    Telechat:

  6. MPLS Upstream Label Assignment and Context-Specific Label Space
    draft-ietf-mpls-upstream-label-05.txt
    Token: Ross Callon
    Discuss:
    1. Jari Arkko: Discuss [2008-05-06]:
      I believe that there is a need for upstream labels, and that we need to have a document that specifies them. However, there are technical issues in this document that need to be corrected before this document can move forward:
      1. The document discusses the concept of a context. The documentalso requires that the label distribution protocol be able to indicate the use of upstream labels. But merely knowing that upstream labels are used is not a sufficient condition for the correct processing to occur. The endpoints must also have the same understanding of what context to use. I would suggest that the document require the communication of context as well. Such communication can be explicit "here's the context" or implicit "for protocol X, the context is always the source address of the signaling message used to set the label up".
      Perhaps the latter is what the text in Section 7 attempts to do?
      If the tunnel on which Rd receives MPLS packets with a top label L is a MPLS tunnel, then Rd determines a) That L is upstream-assigned and b) The context for L, from the labels above L in the label stack.
      But if so, it needs to be more clearly stated. I cannot determine if the above statement says all MPLS tunnels will be upstream assigned, or if the appearance of a specific label L will cause the receiver to determine that the following labels are the context.
      2. What is the upstream label space that Rd reserves for Ru to allocate specific values from? The entire syntactically available label space? Something that is agreed upon between the two entities? This needs to be specified, and if the two entities need to agree on it, that must be a requirement for the label distribution protocol.
      3. If a downstream node Rd has received an upstream label L from node Ru with context C, what guarantee there exists that there is no other upstream node that uses the same context C for MPLS packets (with either upstream or downstream labels)?
      Perhaps the answer relates to the definition of contexts (item 1) but this isn't clear from the document.
      4. Both IPv4 and IPv6 need to be addressed in a specification that does not relate to something intrinsic to only one of them. In some cases we have approved specifications where we knew there was a corresponding v4/v6 counterpart in the works. Is there one in this case -- after a brief search I could not find one? If not, Section 8 needs to be complemented with a specification that works for IPv6 as well.
    2. Lisa Dusseault:Discuss [2008-05-06]:
      This is a DISCUSS entered so that I can get a better understanding of this document and the significant changes it introduces, before we move quickly onward.
      Upstream-assigned labels change the RFC3031 architecture quite significantly. Since it has the support of both Routing ADs and is the basis for a bunch of further work in MPLS, I can only assume it's had significant review. I did some searching, however, and was unable to find direct evidence of that review -- e.g. the WGLC seemed to receive no replies.
      Also, I don't usually look for a bunch of justification and requirements in standards, but for this big a change I'm definitely looking around. It took me a while to arrive at RFC3353 sections 9 and 10.4 -- and section 10.4 lists benefits for downstream-assignment as well as upstream.
      I'm particularly interested in the backwards-compatibility and security characteristics of this change. Do we have implementation experience on this yet?
      - Section 5 talks about assigning labels that do not conflict with downstream-assigned labels, but all the requirements are SHOULD (and even 'could'). Aren't conflicts here bad?
      - Don't downstream-assigned labels give downstream LSRs a great deal of control over how labels are subsequently looked up? Is this practically of little value? Should upstream-assigned labels be used sparingly -- or in *preference* to downstream-assigned labels -- or is there really no preference?
    3. Lars Eggert:Discuss [2008-05-08]:
      INTRODUCTION, paragraph 13: RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space".
      Discuss-discuss: Does this document describe a new mandatory-to-implement update to the MPLS architecture?
      Comment [2008-05-08]: I agree with Jari's and especially Lisa's DISCUSSes.
    4. Pasi Eronen: Comment [2008-05-07]:
      I agree with Jari's DISCUSS about handling IPv6.
      Stephen Farrell's SecDir review identified a number of places that were slightly difficult to understand, and could benefit from some minor editorial changes.
      It wouldn't hurt if the security considerations text contained a pointer to draft-ietf-mpls-mpls-and-gmpls-security-framework.
    5. Russ Housley: Comment [2008-05-07]:
      Section 8 says: The procedure described below applies to LSRs using IPv4 and does not apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside the scope of this document.
      I hope this is a heads up that another document is coming.
    6. Tim Polk: Discuss [2008-05-07]:
      This is a discuss discuss and I fully expect to clear before the telechat. However, I am curious:
      draft-ietf mpls-multicast-encaps includes the statement "Unicast labels MUST be downstream-assigned." I suspect this will demonstrate my lack of mpls clue, but I did not get that from this document. Is there a discontinuity here?
      Comment [2008-05-07]: [I know I'm beating a dead horse, but that is why it's a comment rather than a discuss.]
      While the document does not address procedures for distributing upstream-assigned labels, there is a section (6) describing the requirement to do so. If there are known security considerations that apply to this requirement it would be useful to say so in the security considerations. Inclusion by reference is fine, of course.

    Telechat:

  7. MPLS Multicast Encapsulations (Proposed Standard)
    draft-ietf-mpls-multicast-encaps-09.txt
    Token: Ross Callon
    Discuss:
    1. Lisa Dusseault: Comment [2008-05-06]:
      In the Abstract, the doc says: "Both codepoints can now be used to carry multicast packets."
      For accuracy, this should be something like "Both codepoints can now carry both types of traffic."
    2. Lars Eggert: Discuss [2008-05-08]:
      Section 2., paragraph 5: This document updates RFC 3032 and RFC 4023 by re-specifying the use of the codepoints. Note that an implementation that does MPLS multicast according to RFC 3032 and/or 4023 will be unable to interoperate with implementations that do MPLS multicast according to this document. Any attempt to interoperate two such implementations will result either in black holes or in misrouted packets. However, since to the best of our knowledge MPLS multicast done according to RFC 3032 has never been deployed, it is believed though that this does not present a problem in practice. This document specifically deprecates the multicast data plane as specified in RFC 3032.
      Discuss-discuss: Wouldn't it be better to assign a new codepoint, instead of redefining the original "multicast" codepoint, in order to eliminate the potential for interoperability issues? Or are we extremely short on codepoints?
    3. Russ Housley: Comment [2008-05-06]:
      Vijay Gurbani provided a Gen-ART review of -07 on 25 Apr 2008.Since then -08 and -09 have been posted, yet the minor concernsthat were pointed out have not been addressed. Vijay said:
      - S3, second paragraph: s/If Ru and RD/If Ru and Rd/
      - Same paragraph: you may want to consider terminating each numbered item except the last one with a comma.
      - S3, the numbered list towards the *end* of the section: You may want to consider terminating each numbered item with a period.

    Telechat:

  8. OSPF Based Layer 1 VPN Auto-Discovery (Proposed Standard)
    draft-ietf-l1vpn-ospf-auto-discovery-05.txt
    Token: David Ward
    Discuss:
    1. Pasi Eronen: Discuss [2008-05-05]:
    2. The document should explicitly say something about its applicability to OSPFv3 and IPv6-only networks. Unless I'm misunderstanding something, it seems the spec is IPv4 only, although the IPv6 case could be handled in the same document with little extra effort?

    Telechat:

  9. Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) (Proposed Standard)
    draft-ietf-hokey-emsk-hierarchy-05.txt
    Token: Tim Polk Note: proto shepherd is Charles Clancy
    Discuss:

    Telechat:

  10. BGP-based Auto-Discovery for Layer-1 VPNs (Proposed Standard)
    draft-ietf-l1vpn-bgp-auto-discovery-04.txt
    Token: David Ward
    Discuss:
    1. Pasi Eronen:
      Discuss [2008-05-05]:
      Process comment: Sandy Murphy's SecDir review needs a response.
      As noted in Sandy Murphy's SecDir review, this document seems to expand the L1VPN concept significantly beyond the scope of RFC 4847 and draft-ietf-l1vpn-applicability-basic-mode, both of which explicitly rule out inter-as/inter-provider L1VPNs. Expanding the scope of inter-AS/inter-provider VPNs makes the assumption about transitive trust of all BGP speakers rather dubious.
      Comment [2008-05-05]:
      Sandy's SecDir review also identified a number of places that would benefit from some clarification of the text, and provided editorial comments that should be taken into acccount.

    Telechat:

  11. LDP extension for Inter-Area LSP (Proposed Standard)
    draft-ietf-mpls-ldp-interarea-03.txt
    Token: Ross Callon
    Discuss:
    1. Tim Polk:Comment [2008-05-07]: (As noted by Shawn Emery in his Secdir review)
      In section 4,
      s/set-up the fist inter-area LSPs/set-up the first inter-area LSPs/
    2. David Ward:Discuss [2008-05-05]:
      Several points that I'll try to make as coherent as possible ...
      - My biggest issue is that the draft doesn't solve the problem it set out to solve and has no scale benefits. It addresses to some degree the control plane aspects - allowing the IGP to summarize. But this is very small compared to updating the data plane. They get rid of the /32 IP routes in the data plane, but still require labels for all those routes. All such labels may need to be updated on a re-convergence event.
      - Next, the idea ties BGP NH tracking directly to LDP. The major con is that NHs are provided the IGP and NH tracking should not be completed via ordered LDP update/withdraw but, the IGP. The clear drawback is the change to BGP NH validation.
      - In the end, the only reason for deploying this draft would be that you want each P router to have an LSP for each /32 PE router address, so that you can take advantage of LDP-based FRR. Since there is no such thing as LDP support for FRR, this seems a poor reason.
      DISCUSS DISCUSS
      - There are multiple competing solutions in this space from a variety of authors. Pushing this one forward to PS with no known implementations (choice of the MPLS WG) and knowing that other more complete solutions are being proposed seems to give us a chance to pause to think through the entire solution space. I highly recommend we convene a discussion of MPLS saavy folks and work through the possible solutions that will have to be considered and see if we can reduce from the three known to "the chosen one." Unfort., I don't think it will be this one.

    Telechat:

  12. IMAP CONVERT extension (Proposed Standard)
    draft-ietf-lemonade-convert-18.txt
    Token: Chris Newman Note: Eric Burger is the document shepherd
    Discuss:
    1. Jari Arkko: Discuss [2008-05-08]:
      I am concerned about the underspecification of the NIL conversion, and the lack of warnings about the interoperability issues. There are good reasons for this functionality, but as currently defined it can lead to problems and this specification does not adequately describe the issues.
      Specifically, the main use cases that I see for NIL conversion are:
      1. Defaulting to a commonly available format. You see an unrecognized media type and have no clue what it is; you ask for conversion to a commonly used media type and hope that you support it.
      This is fine. But the document says: Servers are REQUIRED to support "default conversion" requests.
      I do not know how to implement this, or how to test if aproduct is compliant. I would suggest Section 7.1 be amended to specify the mandatory-to-support default conversions.
      2. Defaulting to a format that the server knows is suitable for the client. The document states that how the server knows this is outside the scope.
      This is problematic. I agree that there may be cases where this is possible, and I support the idea that the document allows this. However, I suspect that the cases where people are thinking of applying this actually have more heterogeneous clients than people might beliueve. There are mobile networks, for instance, with a lot of bundled device offerings from the service provider. However, mobile networks where other, commercially acquired devices cannot be used as well are almost extinct. For instance, even if an operator offers XXX phone to their customers, I can buy an YYY phone and insert the correct SIM card, and it works. If the provider's e-mail server starts making assumptions about what devices can do, the chances are that they will guess wrong.
      I would like Section 6 to contain a very clear warning about this. You may also consider adding a requirement that the client capabilities be communicated some manner (even if that manner is unspecified; the point is that guessing based on what server admin thinks the clients are is wrong).
    2. Lars Eggert: Discuss [2008-05-08]:
      DISCUSS: Document uses the term "REQUIREs" in several places. This it not an RFC2119 term. Please rephrase using MUST, REQUIRED or SHALL, which are the three RFC2119 terms for the "mandatory" requirement level.
    3. Pasi Eronen: Comment [2008-05-06]:
      Section 7, "IMAGE/JPG" -> "IMAGE/JPEG"
    4. Tim Polk:Discuss [2008-05-07]:
      This is a discuss discuss. I was wondering where the reader could go for more information on the APPEND/CONVERT attack noted in paragraph 4 of section 11 (Security Considerations). Specifically, are there any actions a server can take to protectc itself beyond logging? I took a quick look at RFCs 3501 and 3502, but didn't see anything...
    5. Dan Romascanu: Discuss [2008-05-07]:
      The DISCUSS is based on the OPS-DIR review performed by David Harrington on draft-17. A number of issues were discussed on the lemonade list and fixed, but it looks that draft-18 did not address this issue:
      Manageability is not discussed in this document. I do not know if there would be anything new required as a result of this extension, but it might be useful for an operator to be able to tell how often this extension is being used and by whom and the number of errors, to help detect abuse and performace-impacting situations.
    6. Magnus Westerlund: Discuss [2008-05-07]:
      General comment
      Media type parameters:
      What I can read no media type parameters can be included in any of the commands. That makes it impossible in for example conversion to specify which profile and level for example a video conversion needs to fit into. Please explain how you can avoid handling media type parameters to deal with more specific handling of some media types.
      I think including parameters are especially important in the case of using Conversions to indicate capabilities
      Section 10: conversion-data = "CONVERSION" SP quoted-from-mime-type SP quoted-to-mime-type [SP "(" transcoding-param-name *(SP transcoding-param-name) ")"
      This construct is missing a closing "]".
      As a comment it would have been easier if to determine if the ABNF was correct if one included all the missing rules, at least by "hand-waving" imports, i.e rule = <see section x.y in RFC YYYY>

    Telechat:

  13. User-Defined Errors for RSVP (Proposed Standard)
    draft-ietf-tsvwg-rsvp-user-error-spec-07.txt
    Token: Magnus Westerlund
    Discuss:
    1. Jari Arkko: Discuss [2008-05-08]:
      A discuss-discuss that I may clear after getting more information. The definition of the "Error description" field employs US-ASCII. I question the idea of introducing new protocols or new fields that employ ASCII; wouldn't UTF-8 make more sense?
      But how useful this would be in this case depends on the intended purpose. The spec does not clearly say that this is information that could be displayed to the end user. Is it? If not, ASCII is fine. If yes, please be more clear about it and transport UTF-8. The current says "this information is typically printable", which does not tell me much about how I should implement it on my device.
    2. Pasi Eronen: Comment [2008-05-05]:
      Based on Stephen Hanna's SecDir review: especially since RSVP packets don't usually contain ASCII strings, it might be a good idea to say in security considerations that the received string must be processed carefully (as it could contain e.g. control characters, printf format strings, SQL injection, or whatever). Stephen's suggested text:
      Like any other data received from a partially trusted party, the recipient MUST carefully check the USER_ERROR_SPEC object and its contents to make sure that it does not contain any malformed or illegal values and will not cause any buffer overruns or other processing errors that could cause reliability or security problems. The Error Description should be examined especially carefully if it is to be logged or displayed since it may eventually be processed by other code with poor error handling. Any control characters (bytes with values 0-31 and 127 decimal) or non-ASCII characters (128-255 decimal) MUST be removed. Other characters may need to be removed from the string, depending on the logging system in use and the range of characters that it can accept. If the logging or display system has escaping or another post-processing step that could give special meaning to the characters in the string, protection against injection attacks SHOULD be included in the RSVP code.
      Typos:
      In section 3, "Criticial" should be "Critical".
      In section 4.2, "display of logging" should be "display or logging".

    Telechat:

2.1.2 Returning Items

  1. none

2.2 Individual Submissions

2.2.1 New Items

  1. Simple Mail Transfer Protocol (Draft Standard)
    draft-klensin-rfc2821bis-10.txt
    Token: Lisa Dusseault
    Discuss:
    1. Jari Arkko:Comment [2008-05-08]:
      On the call, I would like to hear how the MX/AAAA debate was resolved.
    2. Lars Eggert:Comment [2008-05-08]:
      Agree that example domain names and IP ranges should be used. Giving credit to Jon is best done in the acknowledgment section, IMO, or maybe a compromise would be to use "usc.edu.example.org" and "isi.edu.example.org" (unfortunately there is no example.edu).
      Section 2.3.1., paragraph 2: Historically, variations on the reverse path (originator) address specification command (MAIL) could be used to specify alternate delivery modes, such as immediate display; those variations have now been deprecated (see Appendix F and Appendix F.6).
      It might be useful here and elsewhere where the draft refers to RFC821 features that RFC2821 has deprecated (i.e., stuff in Appendix F), that these features have been deprecated for years now and that they should _really_ not be used anymore.
      Section 550, paragraph 1: Sites implementating SMTP authentication may choose to make VRFY and
      Nit: s/implementating/implementing/
    3. Pasi Eronen: Comment [2008-05-07]:
      It seems that in the terminology of this document, an SMTP system doing DKIM signing would be a "gateway" (or possibly "originator"), but not "relay" (since relays are not supposed to insert other headers than Received).
      Since DKIM allows "a signing domain to claim responsibility for the introduction of a message into the mail stream", calling it a "gateway" seems fine, and I don't have any objections to this choice of terminology.
      (Perhaps it would be a good idea to explicitly say that e.g. DKIM signers, spam filters that add header fields to messages, and so on, are considered "gateways" in this terminology.)
    4. Russ Housley: Discuss [2008-05-07]:
      http://www.ietf.org/IESG/implementation.html does not seem to include an implementation report for this document. Scott Hollenbeck raised this point on 30-Nov-2007 in a Last Call comment, but a report has not appeared.
      Section 4.3.1 uses "isif.usc.edu" as an example. Some of the examples in the appendices also use non-example hostnames. Please use example.com in the examples.
    5. Chris Newman: Comment [2008-05-05]:
      FYI, to compare with previous RFC try this URI:
      http://tools.ietf.org/rfcdiff?url2=http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-10.txt&url1=http://www.ietf.org/rfc/rfc2821.txt
      To be consistent with RFC 2821, this needs a header: Updates: 1123
      The following is not valid ABNF (looks like an accidental typo):
      Standardized-tag ; MUST be specified in a standards-track RFC and registered with IANA
      I suggest:
      Standardized-tag = Ldh-str ; MUST be specified in a standards-track RFC and registered with IANA
      or
      Standardized-tag = <As specified in future standard> ; MUST be specified in a standards-track RFC and registered with IANA
      Suggestion: STD 66 (URI RFC 3986) defines an "IPv6address" rule that could be referenced or copied. It got the ABNF cleaner than we got it here (and yes, that ABNF was my fault in RFC 2821 but I recognize when someone else does it better).
    6. Magnus Westerlund:Discuss [2008-05-07]:
      Section 4.1.1.3:
      The examples uses domain names that aren't drawn from the example range. At least "xyz.com", "foo.org", "bar.org" is actually owned by someone. I don't think these names should be used in this document.
      Section 4.1.3:
      Standardized-tag ; MUST be specified in a standards-track RFC and registered with IANA
      This rule is not a rule. What I can guess from the context, this should be defined be something like:
      Standardized-tag = token ; MUST be specified in a standards-track RFCand registered with IANA
      token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7A / %x7C / %x7E)
      The ABNF also gets some warnings in addition to the above errors:
      warning: rule Forward-path previously referred to as Forward-Path
      warning: rule QcontentSMTP previously referred to as qcontentSMTP
      warning: rule address-literal defined on line 85 referred to as Address-literal
      It would also be easier if one included handwaving import rules for rules defined in other documents like:
      atext = ST See section 3.2.4 in RFC 2822 LT
      Where ST is Smaller than sign and LT is larger than.

    Telechat:

2.2.2 Returning Items

  1. none

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Guidelines for IP Flow Information eXport (IPFIX) Testing (Informational)
    draft-ietf-ipfix-testing-05.txt
    Token: Dan Romascanu Note: Nevil Brownlee is the PROTO shepherd
    Discuss:
    1. Pasi Eronen: Discuss [2008-05-06]:
      Section 3.7.1 (about testing TLS and certificate-based authentication) says that the "tester must configure consistent forward (A, AAAA) and reverse (PTR) DNS records for each host in the test".
      The role of PTR records here needs some clarification -- why are they needed at all? (The reason I'm asking is because one obvious use would be to match the result of PTR lookup against the name in the certificate -- but that isn't such a great idea.)
    2. Tim Polk: Comment [2008-05-08]:
      This document does not provide guidance on the testing context. Should these procedures be applied in a testbed environment or on live networks?
      It would seem that certain tests would need to be very carefully constructed (e.g., stress/load tests and network disconnect) to avoid impacting other systems on the network.

    Telechat:

3.1.2 Returning Items

  1. none

3.2 Individual Submissions via AD

3.2.1 New Items

  1. The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header) (Informational)
    draft-vanelburg-sipping-served-user-05.txt
    Token: Jon Peterson
    Discuss:
    1. Russ Housley:Discuss [2008-05-07]:
      There was a Gen-ART Review of draft-vanelburg-sipping-served-user-04.txt by Francis Dupont. A new version of the document has been posted, but there was not a reply to the review. The suggestions in the review were clearly not accepted, so a reply is needed.
      There was a SecDir Review of draft-vanelburg-sipping-served-user-05.txt by Sandy Murphy. There has not been a reply to this review either.
    2. Cullen Jennings:Discuss [2008-05-06]:
      The security section is not adequate to meet the security needs this draft describes. When it says that a proxy "MUST not insert the header unless ..." it really means "the PROXY MUST remove the header unless ....". To ensure that proxy does this, you need to ensure that proxy actually supports this specification since ones that did not would not remove the header and thus not meet the security requirements. To ensure this, I suspect you need a Proxy-Require option tag.
    3. Tim Polk: Discuss [2008-05-08]:
      In the absence of a discovery mechanism, the security of the P-Served-User header field seems to rely on manual configuration of a database of P-Served-User aware proxies within the given trust domain. It might be a good idea to describe the contents of this database, and note that the protecting the integrity of this database is critical.

    Telechat:

  2. Experience of implementing NETCONF over SOAP (Informational)
    draft-iijima-netconf-soap-implementation-07.txt
    Token: Dan Romascanu
    Discuss:
    1. Jari Arkko: Discuss [2008-05-07]: Discuss-discuss.
      I would have voted Yes on this document, if it were not for one detail. I am looking at Section 3.2.1 that says one need not implement the SOAP encodingStyle attribute, or the SOAP header inside a SOAP envelope, if "memory is tight".
      I wanted to check the SOAP spec for whether this was actually legal. I was unable to find any statement regarding what SOAP actually requires as mandatory to implement. The relevant section
      http://www.w3.org/TR/soap12-part1/#soapencattr
      only says that the attribute MAY appear. To me that sounds like it does not have to be present on the wire, but the endpoints have to be able to understand it if it is.
      But I would like some SOAP expert to weigh in on this.
    2. Pasi Eronen: Discuss [2008-05-08]:
      Discuss discuss: We don't usually publish documents whose title could be "Beginner's Guide to Apache Axis". I didn't review those parts (since I'm not even a beginner with this particular tool). For an Apache Axis tutorial, it doesn't look particularly good; and it doesn't seem to have much NETCONF specific content. Fine text for a web page, perhaps, but I don't quite understand why it would be a good fit for the RFC series.
      However, there's one place where it's not clear whether the text is just explaining how things work, or actually specifies new behavior that is not part of the current RFCs. Specifically, Sections 3.1.2 and 3.2.2 seem to specify a different approach to maintaining sessions than what is used in RFC 4741/4743.
      Additional comments:
      Section 2.1 suggests that using SOAP/HTTP for NETCONF means we also get things like WS-Security, WS-Reliability, etc. -- this is not really true; RFC 4743 doesn't use e.g. WS-Security.
      Section 3.1.2 says HTTP creates TCP connection for every request; this hasn't been true for at least 10 years.
    3. Chris Newman: Discuss [2008-05-07]:
      I wonder if a brief IESG note along the lines of the following would be a good idea:
      ---
      IESG Note:
      RFC 4741 section 2.4 states, "A NETCONF implementation MUST support the SSH transport protocol mapping."
      ---
      While I appreciate and value the input this document provides to the IETF, we choose mandatory-to-implement facilities to promote interoperability and I wouldn't want this document to accidentally mislead a reader. Note that I will change my position to no objection after the IESG discusses this unless the IESG has rough consensus in favor of this sort of a note.
    4. Tim Polk: Comment [2008-05-08]:
      In section 3.1:
      s/Apache Axis is the widely used/Apache Axis is widely used/
    5. David Ward: Discuss [2008-05-08]:
      Section 3.2.2 is too restrictive (aka not generic enough) and doesn't cover enough state machinery to fully describe session maintenance.
    6. Magnus Westerlund:Discuss [2008-05-08]:
      3.1.2. Session Maintenance in NMS
      When exchanging NETCONF messages between an NMS and networkequipment, implementation of a session-maintenance function is necessary on both sides.
      HTTP is a stateless protocol that is used as an underlying transport protocol for SOAP. HTTP creates and terminates a TCP session at every request. Therefore, when using HTTP as a transport protocol for SOAP messages, session maintenance at the TCP level as well as at the NETCONF level is necessary. Unless a session is maintained at the TCP level, a different NETCONF service provider is invoked every time the NETCONF client sends a NETCONF message to the NETCONF server. We used a cookie field inside a HTTP header as a session identifier for the session on TCP level.
      The session-maintenance function at the TCP level has to be incorporated as follows. After the NETCONF application sends a NETCONF hello message to a NETCONF service provider, the application receives a newly allocated session identifier written in the cookie field of a replying hello message. The NETCONF application preserves the cookie paired with the network equipment's MAC address and uses it as a session identifier for subsequent NETCONF message exchanges. When an NMS sets the cookie for subsequent NETCONF messages, the network equipment recognizes the session and maintains it. The stored cookie is erased when the NMS sends a close-session message and a response message is received from the network equipment.
      I am a bit uncertain if I understood this correctly but to me the above text seems to have some issue.
      1. "HTTP creates and terminates a TCP session atevery request."
      This is not true if HTTP 1.1 support for persistent connections are used.
      2. Secondly, the closing of the TCP connection seems to be breaking the RFC 4743 rules for session handling.
      3. "The session-maintenance function at the TCP level has to be incorporated as follows."
      This text seems to imply that this document is redefining RFC 4742.
      4. I don't understand why MAC address has to be maintained can you please clarify why that would be necessary?
      General discuss discuss:
      I think it is great that this type of document gets writtne. However, I think this document has somewhat the wrong tone for its intention. On several places it has wordnings such as: "must have", "must use", "needs" instead of "we used" "may use" as this is intended to describe what the document authors did rather than
      example:
      The development of a Java-based NETCONF client needs JDK (Java Development Kit) [JDK] and Apache Axis.

    Telechat:

3.2.2 Returning Items

  1. none

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. IAX: Inter-Asterisk eXchange Version 2 (Informational)
    draft-guy-iax-04.txt
    Token: Cullen Jennings
    Discuss:
    1. Chris Newman:Comment [2008-05-08]:
      I don't believe the specification has enough information to implement the MD5 and RSA authentication mechanisms.
      Have the authors considered a mechanism to activate DTLS (4347)?
    2. Magnus Westerlund: Discuss [2008-05-08]:
      The note should cover the other WGs that also are doing work in this space, i.e. AVT and MMUSIC, maybe also mediactrl.
      I am also worried that this specification seems to have a very simplistic mechanism for indicating congestion. It is also unclear what type of congestion they are talking about, call arrival or traffic induced network congestion. I think we need a more explicit IESG note for this.

    Telechat:

  2. Licklider Transmission Protocol (Three Documents)
    draft-irtf-dtnrg-ltp-09.txt
    draft-irtf-dtnrg-ltp-extensions-07.txt
    draft-irtf-dtnrg-ltp-motivation-06.txt
    Note: Recommend RFC 3932 response #1: The IESG has not found any conflict between this document and IETF work.
    Token: Russ Housley
    Discuss:
    1. Pasi Eronen: (blank)

    Telechat:

1245 EDT break

1252 EDT back

3.3.2 Returning Items

  1. none

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Source Address Validation Improvements (savi)
    Token: Jari Arkko

    Telechat:

  2. Data for Reachability of Inter/tra-NetworK SIP (drinks)
    Token: Jon Peterson

    Telechat:

4.1.2 Proposed for Approval

  1. none

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. RADIUS EXTensions (radext)
    Token: Dan Romascanu

    Telechat:

  2. Mobility EXTensions for IPv6 (mext)
    Token: Jari Arkko

    Telechat:

4.2.2 Proposed for Approval

  1. none

5. IAB News We can use

  1. Loa: pasted into Jabber. Mtg yesterday re liaison shepherding. Will assign IAB member to work with each liaison.
  2. Five Architecture topics
  3. ENUM feedback
  4. RFC structure: RFP next year, some breakup of tasks - four parts - will put out to wider community for discussion
  5. P2Pi will have at least 5 IAB members present

6. Management Issues

  1. Should default welcome message for IETF lists have the Note Well (Cullen Jennings)

    Telechat:

7. Agenda Working Group News

1326 EDT Adjourned