IESG Narrative Minutes

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

Narrative scribe: John Leslie (The scribe was often uncertain who was speaking. Instances of "UserNN" are Webex IDs.)

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. NACK-Oriented Reliable Multicast Transport Protocol (Proposed Standard)
    draft-ietf-rmt-pi-norm-revised-13
    Token: Magnus Westerlund; : Document Shepherd: Lorenzo Vicisano <lorenzo@vicisano.net>
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-06-18]: I wanted to talk about this on the IESG call today before we approve the document:
      The recommendations for generating source_id values are fairly unspecific. Is there a need to specify something which is mandatory to implement, and is there a need to clearly say what to do with IPv6 addresses as well?
    2. Adrian Farrel: Comment [2009-05-31]: I find language like "is designed to" rather timid! If you want this to be a standard you need to be a bit more robust in your assertions.
      The term NormNode is used in section 1.2 before its definition in section 2.
      Section 4.1 "source id"; s/the host IP/the host IPv4/
      There are several uses of capitalised non-2119 language. No law against this AFAIK, but may be helpful to convert to 2119...
      It would be really helpful if you collected together in a new section all of the configurable elements of the protocol (timers, policies, etc.).
    3. Russ Housley: Comment [2009-06-02]: Editorial from the Gen-ART Review by Vijay Gurbani:
      1) In S8, you may want to expand the acronym "DBS" (I think you mean Direct Broadcast Satellite, but I am not sure.)
      2) In S10, there is a phrase, "(and these are not Negative)" -- is this a leftover from previous edit sessions?
    4. Tim Polk: Comment [2009-06-16]: I am entering this as a Comment since I missed this on my first review, but I would have strongly considered a DIscuss if this was my initial review.
      I do not believe the "Baseline Secure NORM Operation" described in section 7.1 is sufficient for interoperable implementations. The document does not indicate whether IPsec version 2 or 3 should be supported, or the appropriate version of IKE. (The normative references are for IPsec version 3, so perhaps the first decision has been made?) Identifying three automated key management schemes (GDOI, GSAKMP, and MIKEY) in 7.1.2.3 is helpful, but an implementation is forced to support all three for interoperability. Is there a reason that we can't give more specific guidance?
      BTW, I have requested another review from an IETFer with more IPsec expertise. I will revise my comment yet again if she identifies further interoperability problems... add additional points
    5. Dan Romascanu: Discuss [2009-06-01]: I am still reading this document which seems well written, but it is not easy reading. I do want however to ask two questions and in case these remain the only questions I plan to clear my DISCUSS at the meeting or when I get clarifying answers.
      1. What are the conclusions of the experiment that led the WG decide that it is appropriate to advance this document from the Experimental Status of RFC 3940 to Proposed Standard? The list of changes from RFC 3940 does not provide enough information on this respect. How widely was the protocol deployed? what are the conclusions about its scalability and reliability?
      2. How is this protocol and in general the technology defined in the RMT working group going to be managed? This is related somehow to the first question, I would expect that around a protocol that was at Experimental for a number of years and is now going to Proposed standard have some information gathered about its operational model and impact, and about the management methods and proocols that would be suitable to be used for various management operations.

    Telechat:

  2. Tags for Identifying Languages (BCP)
    draft-ietf-ltru-4646bis-23
    Token: Alexey Melnikov; Note: Martin Dürst is the document shepherd
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-06-16]: I'm very happy to see that Klingon is supported ;-)
    2. Lisa Dusseault: Comment [2009-06-16]: The reference to 2028 isn't normative. That reference merely describes the IESG. The reference to 2026 is normative because the process defined here builds on a process defined in 2026.
      The reference to 2277 isn't normative. It's documentation of how a decision was made, not required "to implement" or even to understand langtags.

    Telechat:

  3. Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) (Proposed Standard)
    draft-ietf-ltans-dssc-09
    Token: Tim Polk
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-06-17]: This is in general useful work.
      On the IESG telechat, I would like to talk about one aspect that I either did not fully understand or there is a problem.
      Section 4 talks about registering parameters through standards action, and specifies the parameters for the two public key signature algorithms.
      I understand that this document is on the standards track. I do not think that parameter definitions for all possible algorithms necessarily need to be. For instance, an algorithm published on the RFC Editor track as Experimental would be cumbersome to register for its parameters in a standards track RFC.
      Or am I missing something? I am also troubled by the fact that some of the text and constructs in the document are generic, i.e., talk about ALL cryptographic algorithms but some other text seems to assume we only need to do this for public key signature algorithms, or their combination with hash algorithms. Can I use this document for talking about the policy for AES keylength=128,192,256? Would the key lengths be parameters?
    2. Ralph Droms: Comment [2009-06-16]: I don't understand this bullet item from the list in section 5.1:
      o Time of interest (optional). Providing no time of interest means determination of the validity end date of algorithm.
      Also, as a clarification, do I understand correctly that the time of interest is an absolute time identifying the time for which the algorithm policy is to be evaluated?
    3. Pasi Eronen: Discuss [2009-06-18]: I have reviewed draft-ietf-ltans-dssc-09, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document:
      - In general, it doesn't matter that much if a protocol/data format uses hand-crafted binary syntax (like most IETF protocols), XML, ASN.1, comma-separated ASCII, JSON, etc. -- all those work and can lead to interoperable implementations. But why does this document specify *two* different data formats for the same information? That would seem to hurt interoperability?
      (I'm hoping there is a better answer than "some WG members liked ASN.1 and others XML" -- that would lead to specifying two or more versions of every IETF protocol!)
      - Is it expected that these policies will be stored in stand-alone files, perhaps downloadable over HTTP? If so, it probably would be good to define MIME types, and for the ASN.1 version, a concrete file format (what's the top-most structure in the document? and what encoding -- BER, DER, PEM, ...?)
      - Could you explain a bit about what the expected granularity of the policies is supposed to be? The example in Appendix E uses OID 1.2.840.113549.1.1.1 for RSA, but public keys with this OID could potentially be used with multiple different RSA algorithms: perhaps PKCS#1 v1.5 RSA signatures, RSA-PSS signatures, ISO/IEC 9796-1/2 signatures, PKCS#1 v1.5 RSA encryption, RSA OAEP encryption, and so on. Would the same policy apply to all of these? (It probably should not, as ISO/IEC 9796-1/2 is known to be broken!)
      Or in general, should the OID be the OID of a particular signature algorithm, or OID of a public key format (which can be potentially used with different algorithms)? In e.g. X.509 certificates, these are usually two separate OIDs...
      - Has the WG discussed what the parameters for ECDSA would potentially look like? Can they be expressed using the current format? (If e.g. some elliptic curve is found to be weak, that's more complex to express than ">1024 bits").
      In addition, there's couple of places that probably need some clarifications:
      - The exact/min/max/range parameters are specified as xs:string (XML version) and OCTET STRING (ASN.1 version). Does this mean they're supposed to be compared as Unicode/octet strings? If integer comparison is intended, the data type probably should be xs:integer/INTEGER?
      - The document doesn't say whether AlgorithmIdentifer.Name contents are intended to be parsed by automatic process, or whether it's intended only to be read by humans?
      - Section 5.2 says the algorithm used to authenticate the policy's signature MUST be suitable according to the policy. The text probably should say that the algorithms used to validate the signature must also be acceptable to local policy? (So that a totally broken algorithm can't be declared suitable by creating a policy with a forged signature.)
      - Although signatures will anyway break if converting from ASN.1 to XML format or back, there's one other place that doesn't fully translate: PolicyName has URI in the XML version, but OID in the ASN.1 one. Is this intentional? If it is, it probably should be mentioned in e.g. Section 3.2.
      - Section 5.4: I would guess that most readers, when seeing an evaluation with '<Min>1024</Min>' would expect it to apply when the parameter value is at least 1024. But it seems the semantics here are exactly the opposite; I suspect this might cause lot of confusion in future. Perhaps Min/Max could just be removed, relying on Range instead? (perhaps allowing omitting the "max" part)
      - The spec doesn't actually tell how OIDs in <ObjectIdentifer> are encoded (if I recall right, the ASN.1 standards actually use a different notation, not the dot-separated one). One way to clarify with would be to specify ObjectIdentifierType in the XML schema with pattern like "(\d+\.)+\d+"?
      - The example XML in Appendix E doesn't actually validate with the schema: there's an extra quote character on line 2115 of the draft, and invalid date on line 1989.
    4. Adrian Farrel: Comment [2009-06-17]: Call me a pedant, but in the Abstract...
      "Since cryptographic algorithms can become weak over the years"
      This is poorly worded. I don't believe the algorithms change in any way. It may be discovered that they were always weak.
      Code fragments appear to be missing license terms. RFC Editor will pick this up, but you can save the IETF money by making the changes now.
    5. Russ Housley: Discuss [2009-06-17]: The Gen-ART Review by Miguel Garcia on 17-June-2009 raises several concerns. A response to the concerns is needed. While the response ought to address all of the concerns, I am especially concerned with these:
      - Please consider RFC 3688, in which case, the namespace of the XML document should be urn:ietf:params:xml:ns:dssc, which would need to be registered with IANA.
      - Please some normative text saying that implementations must implement the XML schema in the document...
      Notice also the normative references to: [xx] [yy] [zz]
      - Please specify an associated MIME type, perhaps "application/dssc+xml".
      - Please clairify 2nd bullet in Section 6, which reads:
      "It must not be possible to alter or replace a security suitability once accepted by the client."
    6. Alexey Melnikov: Discuss [2009-06-17]: These are a minor points and I think they should be easy to address:
      4. Definition of Parameters
      "This section defines the parameter names for the currently known public key algorithms..."
      Is there a single place where OIDs for known algorithms are defined? I think a pointer to IANA registry or an RFC is needed the first time OIDs are referenced.
      Appendix D. ASN.1 Module in 1997 Syntax (normative)
      "[...] Algorithm ::= ..."
      I think the ASN.1 representation can't convey a language tag that can be associated with Information in the XML representation. Is this intentional?
      Comment [2009-06-17]: I am agreeing with Russ' DISCUSS (GenArt comments), in particular I should have picked up lack of the MIME type registration.
      3.11. Parameter
      "The Parameter element has a name attribute..."
      Does this need a new IANA registry?
    7. Robert Sparks: Comment [2009-06-18]: I also had concerns with the text in the second sentence of the first paragraph of section 5.2 (covered in Pasi's discuss). I'd also like to see some information on when its appropriate to violate the SHOULDs in that paragraph.
      Given that the document anticipates new elements (particularly Parameters), please consider a registry for the schema and its extensions.

    Telechat:

  4. More Features for the Two-Way Active Measurement Protocol - TWAMP (Proposed Standard)
    draft-ietf-ippm-more-twamp-02
    Token: Lars Eggert
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2009-06-18]: The authors have proposed text to address Donald Eastlake's SecDir review; it should be included as e.g. RFC Editor note:
      http://www.ietf.org/mail-archive/web/secdir/current/msg00688.html
      Comment [2009-06-18]:
      The document title should be clearer than "More features for TWAMP"; perhaps something like "Mixed Security Mode for TWAMP"?

    Telechat:

2.1.2 Returning Items

  1. Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires (Proposed Standard)
    draft-ietf-l2tpext-tdm-07
    Token: Ralph Droms
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-01-15]:
      Section 1:
      "signaling packets). However, the order of the CESoPSN Control Word"
      The acronym needs to be expanded.
    2. Lars Eggert: Comment [2009-01-15]:
      Section 1., paragraph 3:
      "Setup and maintenance of TDM PWs in MPLS networks using LDP is described in []."
      Missing reference.
      Section 1., paragraph 2:
      "Setup of structure-aware TDM pseudowires using encapsulations described in [RFC5087] has been left for further study."
      In that case, the document title should reflect that. Maybe "Layer Two Tunneling Protocol - Setup of Structure-Agnostic TDM Pseudowires"? The RFC Editor will also likely ask you to expand the TDM acronym in the title (and many of the other acronyms you're using.)
    3. Pasi Eronen: Comment [2009-04-22]: (blank)
    4. Magnus Westerlund: Comment [2009-01-13]: There is quite a lot of non-expanded acronyms in the initial part of the document.
      Especially these ones needs expanding and possibly references:
      Conventions:
      "In this document we refer to control plane as the packets that contain control information (via AVP) and the mechanism that handles these packets."
      Section 1: Is RTP (RFC 3550) here?
      "However, the order of the CESoPSN Control Word (CW) and RTP header (if it is used) MUST match between the TDM data and CE signaling packets."
      Note that there is an acronym overloading here with the word (AVP) as that has one meaning in RTP talk (Audio/video Profile) and another in this document. So RTP AVP in section 2.2 has the potential to be somewhat confusing.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. The Diameter API (Informational)
    draft-ietf-dime-diameter-api-08
    Token: Dan Romascanu; Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the Document Shepherd
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-06-18]: This is a useful piece of work, thanks! Some issues, however:
      AAAServer is returned by one function, but not used anywhere else. As far as I can tell, this seems to be an error.
      AAAReturnCode AAAOpen(char *configFileName);
      "This function must be called before any other AAA function is called. Some of the operations that may be performed by AAAOpen() are: opening and loading the AVP and vendor dictionaries, opening connections with Diameter peers, loading Diameter extension libraries, and registering Diameter callbacks."
      Isn't the registering of callbacks a task for the caller, i.e., first you call AAAOpen and THEN you register callbacks. I do not understand how AAAOpen itself would be registering callbacks automatically. But maybe I am missing something.
      Comment [2009-06-18]: I agree with the other Discusses. The code must compile.
      I did not understand what vendor names are, and how they should be mapped to vendor IDs.
      I did not understand how AAASetServer works if we are not sending to a particular IP address but rather to an AAA server service example.com, possibly behind a number of proxies.
      I did not understand exactly how AAAValue works, but maybe I read the document too fast.
      I think the API could easily have incorporated some security functionality as well, assuming TLS is used at the bottom.
    2. Lars Eggert: Comment [2009-06-16]: I fully agree with Alexey's discusses and comments. If you want to provide a C-language API, it must be syntactically and semantically correct. Otherwise, why bother?
      Additionally, as a convenience to the reader/implementor, it'd be a really good idea if you formatted the draft in a way that made it easy to extract a complete C header file. Look at draft-ietf-nfsv4-minorversion1-dot-x, which did that for an XDR interface - it gives you the shell command to extract the XDR code which can then be directly fed into rpcgen.
    3. Pasi Eronen: Discuss [2009-06-18]: I'd like to discuss with other ADs during the telechat whether this is something IETF wants to publish at all, or perhaps publish as Historic.
      The writeup mentions there being two implementations, but apparently both of them are prototype code from around 2001 that have been abandoned >5 years ago. OpenDiameter (an open source Diameter implementation by the main author of this draft) does not use this API, and to me it looks very unlikely that anyone would ever implement this (and it's questionable whether anyone should even attempt).
    4. Russ Housley: Discuss [2009-06-15]: I could not find any record that the authors ever responded to the Gen-ART Review by Francis Dupont; However, I see that the review was forwarded to WG mailing list:
      From a quick look at the diff between -08 and the version that was reviewed, it does not seem that the comments have been addressed:
    5. Cullen Jennings: Discuss [2009-06-17]: The current IETF license rules around code fragments are very frustrating and hopefully they will change but until they do, this document needs a bit more to address them the current requirements around code in specification. As a side topic, I think it would be highly useful to the the .h file version of this API in an appendix. If you did this, then you could just put the IETF code license on that .h file and solve the code licensing problems.
    6. Alexey Melnikov: Discuss [2009-06-17]:
      3.4.3.7. AAAGetDomainInterconnectType() "The following function returns the domain interconnect type for a particular domain name and type of service:"
      The described return values don't match the actual return type.
      3.4.5.8. AAAFindMatchingAVP() "This function finds an AVP with matching code and vendor id."
      ...The parameters are:
      avp: A pointer to the head of the AVP list.
      This parameter doesn't match the function prototype. Also, one of the first 2 parameters is not described.
      3.4.5.17. AAAConvertAVPToString() "This function converts the data in the AVP to a format suitable for log or display functions."
      How is output truncation due to small destLen value can be discovered by the caller? Is the returned value always NUL terminated?
      In Section 3.6:
      proxyAddress is defined twice using 2 different data types.
      3.9. Callback Processing Order
      "The C API allows API clients to register message processors, or callbacks, that are invoked before and after the bulk of the processing functions for a message. Only one pre- or post-processor is allowed for all incoming messages, regardless of command or extension type. If the API client adds another, any existing pre- and post-processors are removed."
      The last sentence is in conflict with another sentence in the following paragraph:
      "If the client adds a new "First" or "Last" message processor, AAA_ERR_ALREADY_REGISTERED error is returned."
      Comment [2009-06-17]: I am agreeing with the GenArt reviewer that this document would benefit from having a complete .h file.
      1. 2.3. String Format "C API clients are required to format strings as UTF-8 if the string contains 16 bit characters."
        Did you mean "Unicode characters"? They are *not* 16 bits.
        " Since the ASCII characters and the UTF-8 8 bit characters have the same codes,"
        I think you meant to say something like:
        "Since the US-ASCII characters have the same codes when encoded in UTF-8"
        or
        Since all 7-bit UTF-8 bytes represent US-ASCII characters"
      2. In general, I think most (all?) of "char *" input parameters in the document need to be changed to "const char *", otherwise you will get compiler warnings when passing constants.
        For example:
        3.4.1.1. AAAOpen() "The following function is used to open and configure the AAA library:"
        "AAAReturnCode AAAOpen(char *configFileName);"
        Should be:
        "AAAReturnCode AAAOpen(const char *configFileName);"
      3. 3.4.3.4. AAAAbortSession() "The following function, sent by the server, terminates a session:"
        Does this result in the abortCallback (registered in AAAStartSession) being called?
      4. 3.4.3.5. AAALookupServer() "The function looks up the AAA server based on IP address and port number. Server connections are created from the configuration file:"
        Can you explain the last sentence in a bit more details?
      5. 3.4.4.3. AAAValueFromName() "This function looks up an AVP value using the AVP name and vendor name:"
        3.4.4.4. AAAValueFromAVPCode() "This function looks up an AVP value using the AVP id and vendor id, and the value name:"
        This function and one above: what exactly do they do? Maybe you can give an example?
      6. 3.4.5.1. AAANewMessage() "This function allocates an AAAMessage and returns a pointer to it..."
        How is the exact error can be discovered on failure of this function? (There is no AAAReturnCode output parameter anywhere)
      7. 3.4.5.3. AAARespondToMessage() "This function is called to set the AAA Message to the appropriate values, and to inform the library that this message is a locally generated response
        This might be my lack of familiarity with DIAMETER, but I don't think this text is clear. Does this function cause any IO?
      8. 3.4.5.18. AAASetMessageResultCode() "This function decapsulates an encapsulated AVP, and populates the list with the correct pointers."
        Can you elaborate on what this means?
      9. 3.4.6.1. AAASetServer()
        How is this function used? In particular, it is not clear if AAASendMessage() is going to use information set by this function.
    7. Tim Polk: Discuss [2009-06-17]: This is a discuss-discuss. To be clear, I am not requesting any changes in the document at this time, just to discuss it on the telechat.
      Sean Turner raised the issue of API-specific security considerations in his secdir review. In many cases, APIs do not introduce additional security issues, as observed in the subsequent email thread. I am unsure if that is true in this case, however, so I would like to discuss it on the call.
      For example, it is unclear how (if?) an application would indicate whether to TCP or SCTP should (must?) be used as the transport. This is security relevant since SCTP has arguably enhanced security and reliability. There may be other security relevant features that are obscured or cannot easily be set, but I am not savvy enough to know. (I tried to map 3588 to the API and realized I don't have enough Diameter clue to do so quickly!)

    Telechat:

  2. A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP) (Informational)
    draft-ietf-sipping-cc-framework-11
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-06-18]: The flexibility offered by this model is incredible. But I am wondering what it means for interoperability in practice. Are systems employing this model in use, and what do we know of their interoperability across vendors and across potentially different ways to handle calls?
    2. Ralph Droms: Comment [2009-06-18]: Two very minor editorial nits:
      First sentence of section 2.7.1: expansion of acronyms "SIPS"?
      Renumber/reorganize sections 2.6.2-2.6.7 to indicate that these sections all describe "Media Inermediaries", while sections 2.7 through 2.9 discuss other topics?
    3. Adrian Farrel: Comment [2009-06-18]: It seems to me that SIP is getting closer and closer to needing to make routing decisions as multi-segment SIP calls are established, and as SIP servers discover each other and the capabilities of other servers.
      Although not specific, I would like to urge the SIP experts to consult with the Routing Area in order to see whether there is helpful cross-fertilisation that can take place.
    4. Russ Housley: Comment [2009-06-15]: The Gen-ART Review by Francis Dupont raised a few editorial comments that ought to be considered:
      - in Abstract page 2: SIP -> Session Initiation Protocol (SIP)
      - ToC page 3: Far fork -> Far-fork (or Near-fork -> Near fork but fixing the far branch seems better)
      - ToC page 4: Acknowledgements -> Acknowledgments (IETF/RFC Editor spelling)
      - 2.3 page 10: the UA abbrev should be introduced (and IMHO far before)
      - 2.4.2.1 page 12: large- scale -> large-scale
      - 2.6.7.2 page 17: the IVR abbrev must be introduced
      - 3.3.2 page 26: from controller) -> from controller):
      - 3.3.2 page 26: i.e. -> i.e., (same for other i.e. and e.g.)
      - 3.3.5 page 28: a central mixer) -> a central mixer).
      - 3.3.8 page 29 (title): Far fork -> Far-fork
      - 3.2.8 page 30: forked-media -> forked media ?
      - 4 page 30: The class ... include -> includes ?
      - 6.31 page 39: (ex: -> (e.g.,
      - 7 page 39 (title): Acknowledgements -> Acknowledgments
    5. Cullen Jennings: Comment [2009-06-10]: From Gen Art... (essentially the same as Russ above)
    6. Alexey Melnikov: Comment [2009-06-13]:
      6.16. Do Not Disturb
      "In Do Not Disturb, Alice selects the Do Not Disturb option... Do Not Disturb is best implemented in SIP using presence [RFC3264]."
      Should this be referencing [RFC3856]?
    7. Tim Polk: Discuss [2009-06-17]: This is a good document, it reads well, and provides a nice overview of the requirements for multi-party control of SIP.
      However, the Security Considerations need to be enhanced to cover some of the complexities of multi-party control, especially those introduced by the peer-to-peer approach.
      Implementing authentication, authorization, and policy in a peer-to-peer model for establishing conversation spaces seems to introduce new problems:
      (1) If authentication is being performed by "mutually untrusted participants" (bullet eight in the Introduction), then ensuring that consistent levels of authentication were performed becomes very difficult.
      (2) It will be difficult to convey which forms of authentication credentials are acceptable, since different participants may have different capabilities. That is, Alice may be able to validate certificate credentials while Bob can only handle shared keys (or whatever the other possibilities are in SIP).
      (3) Communicating how a participant was authenticated and by whom, in addition to the list of participants, may be important. I also believe that the same types of issues will apply with authorization and policy.
      I don't believe the issues are new (I seem to recall this discussion with respect to the conferencing framework), but they are more complicated in the peer-to-peer model. Perhaps we can refer to security considerations in other documents and note that the issues are exacerbated by the pee-to-peer model.
      Magnus Nystrom posted a secdir review on June 14. I believe many of his comments have merit and would like to discuss one on the call. I have appended the remainder as comments, and request that the authors include Magnus in any discussion of his comments.
      From the secidr review:
      Background
      This document describes a framework for call control and multi-party usage of SIP (while the abstract also talks about requirements, I did not see any strong requirements - at least there are no normative statements in the RFC 2119 sense in the document).
      There are some firm protocol requirements in this document, but I wonder if they are prominent enough without the use of 2119 language. I also recall that use of 2119 language in this type of document is controversial... does anyone else think that a mechanism of some sort to highlight the requirements is needed?
      Comment [2009-06-17]:
      Although brief, the Security Considerations section reads well (a more comprehensive trust/threat model analysis for the proposed framework would have been nice though). It could be useful to add a sentence or two on anonymity aspects in the context of the proposed framework. The body of the text mentions this aspect in passing once (2.6.4) but there is no mentioning in the Security Considerations section.
      In the sixth paragraph, an explicit method for replay attack prevention is recommended (lower-case "should"). I am not sure about the reason for this and could potentially see other ways to mitigate such attacks. Hence, one suggestion could be to replace the current
      "In the case of features initiated by a former participant, these should be protected against replay attacks by using a unique name or identifier per invocation"
      with:
      "In the case of features initiated by a former participant, these should be protected against replay attacks, e.g. by using a unique name or identifier per invocation."
      For clarity, I also suggest changing this section's last sentence to: "These credentials may for example need to be passed transitively or fetched in an event body."
      A question: The third paragraph in the Security Considerations section refers to Section 3.2 - might this be Section 2.3?
      General/editorial:
      - Abstract states "This framework also describes other goals that embody the spirit of SIP applications as used on the Internet" - it would have been useful if this sentence at least had identified a few of these goals.
      - Section 2.3: "peers can take advantage of end-to-end message integrity or encryption" - I would say this applies only when certain conditions are met and hence perhaps something like "peers may take advantage..." or similar would be better.
      - Section 2.6.7.2: Acronym "IVR" introduced without explanation. An early "Acronyms" section would be useful.
      - Section 3: The sentence "One means of accomplishing this is through the ability to define and obtain URIs for these actions as described in section ." seems to be missing the final section reference.

    Telechat:

  3. Network Time Protocol Version 4 Autokey Specification (Informational)
    draft-ietf-ntp-autokey-05
    Token: Ralph Droms
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-06-18]:
      Throughout: s/IPSEC/IPsec/
      Section 13.2: s/Compouter/Computer/
      Section 10 has: "field is present. If the length is less than 4 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the length and then uses the same rules as above to determine whether a MAC is present or another extension field."
      It took me several readings of this to parse correctly (admitedly after being up for 36 hours and flying in from Asia). Could you consider...
      s/length/value of the length field of the extension field that has been found/
      Again in Section 10 "In such cases the Timestamp and Signature Length fields are 0 and the Signature field is empty."
      s/empty/absent/
      Also Section 10:
      It may be helpful to highlight that the contents of the NTPv4 Extension Field Format are not word-aligned. That is, the two length fields (Value Length and Signature Length, which, incidentally, you haven't described) can take values that are not multiples of 4, and that padding is only present at the end of the Extension Field.
      A little odd to have the Security Section embedded at 11.6.
      Section 12 s/PRotocol/Protocol/
      Like Lars, I am surprised that the protocol parts of this specitication are not Standards Track. But if the authors and working group are happy that their protocol extensions will not be implemented or form part of a standard, then that is fine.
    2. Russ Housley: Discuss [2009-06-15]: The Gen-ART Review by Joel Halpern on 5-June-2009 has lead to some discussion with the authors. Not all of the issues have been resolved, but it is clear that some changes to the document are needed. The following issues are still unresolved.
      The usage within Autokey of the extension field need description early in the document. Paragraph 3 of Section 10 reserves seven values (1-7) Autokey. The "Field Type" field performs two roles: identification as an Autokey extension and defining the type within Autokey.
      Section 11.1 includes a 16 bit Digest / Signature NID. There is no description of how this is used.
      The wording on hierarchy in section 5, paragraph 3 is the opposite of what is shown in the figure. (The figure matches expectations, where a client of one group operates as the TH of a group operating at a lower stratum.)
      In Section 10, the paragraph that begins "[T]he extension field parser initializes a pointer..." is incorrect. The "length" by which the pointer is increment is the length in the extension header, not the length computed by subtracting the NTP header from the packet length.
      In figure 5, it would help the reader if the groups and hosts had different names. (Even just calling the groups Alice-Group and Carol-Group would help.)
      In section 5, in the description of "[t]he steps in hiking the certificate trails...", in step 1, in the second sentence, please add language to make it clear that the server is "exchanging host names and negotiating..." with is the server from whom it is getting information.
      Section 8 should be moved earlier in the document. Early parts of the document assume an understanding of properties of the system which have not been described yet.
      Section 11.6 (Security Considerations) is supposed to be a top-level section.
    3. Alexey Melnikov: Comment [2009-06-15]: I know that RFC Editor can fix that, but s/RFC3280/RFC5280
    4. Tim Polk: Discuss [2009-06-17]: [Some parts of this discuss and comments are drawn from Carl Wallace's secdir review posted June 15].
      (1) This specification oscillates between specifying the protocol and documenting the reference implementation. As a consequence, the conformance requirements are unclear in a numbe of cases. The situation could be improved by the usage of 2119 language and by selecting MUST implement features where multiple choices exist. Alternatively, the specification could clearly state that all the features MUST be supported).
      (2) In particular, five identity schemes are supported in the reference implementation. The TC scheme is specified as the default. I would presume the default scheme is mandatory-to-implement, but the expectations with regard to the PC, IFF, GQ and MV schemes are unclear. Given that the MV scheme is "devilishly complicated" it might of particular interest to implementers to learn whether this scheme is required. PC is described as useful for testing only... was this testing restricted to the reference implementation or is it needed when standing up a new system? If it is only for testing the reference implementation, perhaps we should eliminate this text or clearly note as deprecated.
      (3) Guidance on certificate lifetimes and/or revocation processing should be added to the security considerations section.
      (4) Where a server has multiple certificates, does the protocol provide any hint which to use when interacting with dependent clients?
      (5) Section 7 states "All cryptographic values used by the protocol are time sensitive and are regularly refreshed". The security considerations section should probably expand on this concept and provide guidelines for the refresh rate.
      (6) Sections 11.7 and 11.8 are subsections of 11.6 Security Considerations. I believe that these sections should be renumbered as 12 Security Considerations, with subsections 12.1 and 12.2.
      Comment [2009-06-17]: suggest the following global change: s/middleman/man-in-the-middle/
      In section 6, last sentence in paragraph 3: s/details are given in Appendix B/details are given in Appendices B through G./
      Additional specific comments extracted from the secdir review:
      - In section 8 where the Sign Exchange is described, the server is to extract "the subject, issuer and extensions fields" then build a new certificate with that data along with "its own serial number and expiration time" and signed using its private key. There are several potential problems with this, including: the issuer name may be inappropriate, extraction of the public key is not mentioned, revocation is not mentioned (should the certificates have short life times to compensate), the extensions field may have inappropriate values.
      - In 11.4.1, I'm guessing PREV should be PROV. Also, ENB is not expanded anywhere in the draft (elsewhere ENAB is used but also not expanded).
      - In 11.7, a middleman is said to be unable to produce a valid signature. Why is this the case given the trusted certificate is returned by the server? There are no trusted public keys listed in the client state in section 11.3 and the CERT exchange seems to end only when the server sends a self-signed certificate. Assuming the client has a set of trusted public keys (trust anchors), the CERT exchange may work better if the name sent by the client was the name of a trust anchor and the server sent down the full path in one shot.
      - H.2 states that the semantics of certificate fields "generally conforms with conventional usage, there are subtle variations". Some of these variations are problematic. The description of the ExtendedKeyUsage extension refers to populating it with string values. The extension is a sequence of OIDs. Similarly it refers to a string values in basic constraints and keyUsage extensions.
      - The Name example in H.2 should have a SET as the outermost layer (containing the current SEQUENCE). Similarly, the validity example seems to require UTCTime.
      - There are several references to RFC 2510 that should probably be changed to refer to RFC 5280. References to RFC 3280 should be changed to RFC 5280.

    Telechat:

  4. Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS) Traffic Engineering (TE) (Informational)
    draft-ietf-pce-p2mp-app-01
    Token: Ross Callon
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-06-16]: Section 2.2.2., paragraph 0: 2.2.2. PCE Congestion
      Similar to other PCE documents that we've published, I'd suggest to replace "congestion" by "overload" here. In the Internet, congestion implicitly means "data-plane congestion", whereas what is meant here is "control-plane processing overload".
    2. Russ Housley: Comment [2009-06-15]: This is an applicability statement for a piece of protocol that has not yet been written. It is not a re-use of the defined PCE Protocol; the document says that "some extensions are needed." This document is distinct from the p2mp PCE requirements document.
    3. Tim Polk: Comment [2009-06-17]: From Brian Weis' secdir review (posted 6/15)
      The "Note" in the Security Considerations section points out that P2MP computation is CPU-intensive, and posits that an attacker injecting spurious P2MP path computation requests may be more successful than if the attacker injected P2P computation requests. Since you brought up the attack, it would be worth noting that the use of a message integrity mechanism by a PCE protocol should be used to mitigate attacks from devices that are not authorized to send requests to the PCE device. I hesitate to be more specific because the document does not describe a particular PCE protocol.
    4. Dan Romascanu: Comment [2009-06-17]: The OPS-DIR review by Tina Tsou raised a couple of issues. Taking into account that the intended status of this document is Informational I do not believe that these are blocking, however it would be good if they were clarified:
      1. In section 2.2.2, which mechanism is used for the PCE congestion? The congestion notification mechanism is mentioned in the document. When there are not sufficient resources for lager number of PCEs, what to do exactly? The document should specify the detailed mechanisms or some references from other documents.
      2. When the PCEs are not capable of the complex P2MP reoptimization functionality, which other methods may be used?
      I like the Manageability Considerations section. I have a few clarification questions and editorial comments.
      3. in the intorduction to section 8
      "The use of PCE to compute P2MP paths has many of the same manageability considerations as when it is used for P2P LSPs."
      A reference for these manageability considerations would be useful
      4. section 8.2 - it is not clear what is meant by "This will result in much larger data sets to be controlled and modeled and will impact the utility of any management data models, such as MIB modules."
      If you mean that the data model becomes that complex that the efficiency of configuring by SNMP and MIB modules is in doubt - maybe it's better to say it explicitly. Other protocols and data modelling structures lile NETCONF / NETMOD could be considered
      5. In section 8.3 the word 'this' after the period should be capitalized 'This'
      6. Maybe we can find a less colourful term than 'nervous LSRs'

    Telechat:

  5. Update to the Language Subtag Registry (Informational)
    draft-ietf-ltru-4645bis-10
    Token: Alexey Melnikov; Note: Please read 4646bis before reviewing this document. Martin Dürst is the document shepherd...
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-06-17]: (empty)
    2. Adrian Farrel: Comment [2009-06-18]: I don't think the use of the RFC 2119 boilerplate is appropriate. AFAICS, the only use of such language is in instructions to the RFC Editor and the IANA. These instructions will be removed before publication and so the boilerplate is redundant and should be removed.
    3. Russ Housley: Comment [2009-06-15]: From IDnits:
      -- Obsolete informational reference (is this intentional?): RFC 1766 (Obsoleted by RFC 3066, RFC 3282)
      -- Obsolete informational reference (is this intentional?): RFC 3066 (Obsoleted by RFC 4646, RFC 4647)

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Simple SIP Usage Scenario for Applications in the Endpoints (Informational)
    draft-sinnreich-sip-tools-06
    Token: Cullen Jennings; Note: Mary is Proto Shepherd
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-16]:
      Can you add an example of a "Rich Internet Application (RIA)"? BTW, the acronym only needs to be expanded once, at first use (or maybe twice, once in the Abstract and once in the main body of the I-D).
      I couldn't find the examples of controls for RIA at http://flex.org/tour (reference 29). Can you give a more specific pointer or more details on how to find the RIA controls at this site?
    2. Adrian Farrel: Discuss [2009-06-18]: The document write-up is very sparse.
      What level of review has this had from the working groups that handle SIP?
      Although this document is Informational, it seeks to encourage implementers to implement only a profile of the SIP specification. As such, it is a threat to interoperability. It needs the SIP community to approve it.
      Comment [2009-06-18]:
      I don't understand the statement in the Abstract that...
      "For Internet-centric usage, the number of SIP related standards for presence, IM and audio/video communications can be drastically reduced by using only the rendezvous and session initiation capabilities of SIP."
      Surely the objective of this work is not a reduction in the number of "standards". If you wanted to achieve that, you would simply concatenate the text from all existing documents and republish as just one standard.
      Anyway, I don't think your work reduces the number of "standards". I think the real objective of your work is to provide a profile of the existing SIP "standards" that offers an opportunity to reduce the complexity of implementations, reduce the number of features that need to be implemented, and provide an easier assessment of conformance.
      This approach for SIP reduces the number of SIP standards to comply with, currently from roughly 100 and still growing, to about 10.
      I know that 11 is "about 10", but it isn't so hard to count and be precise :-)
      I am suspiscious of the grouping of all references as Informative. Several of these references are necessary prerequisites for understanding this document and should be marked as normative.
      Furthermore, Section 4 is titled "Minimal Set of Mandatory SIP References" and this seems to be in direct conflict with the text in Section 10 that states...
      "Since this is an informative memo, we provide no list of mandatory SIP related standards, but only an informative list of SIP related standards and Internet-Drafts that serve us for the purpose of a simple toolkit for SIP."
    3. Russ Housley: Discuss [2009-06-17]: Despite a nudge by Cullen Jennings, there has not been a response to the Gen-ART Review by Scott Brim on 21-May-2009. Like all concerns raised during Last Call, a response is needed, even no changes to the document are needed.
    4. Alexey Melnikov: Comment [2009-06-15]: I would like to discuss the state of RFC 3428 ("SIP Extension for Instant Messaging") deployments during the telechat. This is mostly for my education.

    Telechat:

  2. Enterprise Number for Documentation Use (Informational)
    draft-eronen-enterprise-number-documentation-01
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-06-16]: I'm missing a short paragraph somewhere (ideally Section 2), that says that this Enterprise Number SHOULD NOT be used for real deployments.
    2. Adrian Farrel: Discuss [2009-06-18]: I'm raising Lars' Comment to a Discuss. Per RFC3330 more information is needed on what is seen on the wire. Further, I think you should describe the behavior of a system that receives the new Enterprise Number. For example, does it simply treat it as it would any other unknown Enterprise Number (perhaps logging or recoreding), or should it specifically ignore the number?

    Telechat:

  3. Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm (Informational)
    draft-housley-aes-key-wrap-with-pad-03
    Token: Tim Polk
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-06-18]: Agree with Lars's question.
    2. Lars Eggert: Discuss [2009-06-16]: Section 7., paragraph 5:
      "A previous padding technique was specified for wrapping HMAC keys with AES [OLD-KW]. The technique in this document is preferred, and the technique in this document is not limited to wrapping HMAC keys."
      DISCUSS: I might be missing something, but RFC 3537 is PS and it's not being obsoleted by anything. How is it appropriate to say that the technique described there is no longer preferred?
      Comment [2009-06-16]:
      INTRODUCTION, paragraph 12: "This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394."
      RFC 3394 not cited.
    3. Pasi Eronen: Discuss [2009-06-17]: Section 7 describes one way how to handle wrapped keys shorter than 9 octets as an example. Why is this just an example, and not part of the actual specification in Section 4?
      (I'm not sure, but e.g. the work in KEYPROV WG might need less than 9 octets when the thing wrapped is a PIN of some kind.)
    4. Adrian Farrel: Comment [2009-06-12]: I may be wrong, but I suspect that the RFC Editor will point out that you have code fragments in this I-D and need to include a BFD license. But, anyway, that is an issue that you will have to resolve in Auth48 if it still remains a requirement.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. Mobile IPv6 Location Privacy Solutions (Experimental)
    draft-irtf-mobopts-location-privacy-solutions-13
    Token: Jari Arkko; Note: The document shepherd is Basavaraj Patil <Basavaraj.Patil@nokia.com>
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2009-06-15]: I'd like to understand more about this recommendation. Did the RG already consider experimental codepoints? Is the RG they receptive to changing them? Are these codepoints really rare?
      This DISCUSS is just to talk about the specific recommendation the IESG will make to the RFC Editor.
    2. Pasi Eronen: Comment [2009-06-17]: Couple of technical comments that are not relevant for the RFC 3932 check, but may be useful for the RFC Editor and/or the authors:
      - It looks like pseudo home addresses won't work as-is when IPsec is used to protect Mobile IPv6 signalling (it looks like they assume Mobile IPv6 part modifies the IPsec Security Policy Database on-the-fly in some unspecified fashion).
      - Pseudo home addresses also seems to introduce a rather big change to Mobile IP: the home agent has to intercept and modify some reverse-tunneled payload packets between the MN and CN (at least HoTI). Currently, these are just normal payload traffic (since the Home Agent is not listed in the "Destination Address" field, it just forwards them without doing any processing). This seems like an ugly layer violation: if the MN has a Mobile IPv6 signalling packet it wants the HA to process somehow, it should put the HA in the "Destination Address" field instead of relying the HA to perform deep packet inspection and "intercept" them.
      - Despite the claim in Section 11, most of this stuff probably doesn't work DSMIPv6 because DSMIPv6 cannot use tunnel mode IPsec to protect binding updates to home agents (when using IPv4 CoA at least).
    3. Tim Polk: Discuss [2009-06-18]: This is probably a trivial discuss, but I would like to see one issue resolved before publication.
      Section 5.1
      If I understand correctly, the encrypted home address is generated by the mobile node and accepted without re-computation by the home agent. If this is correct, there is no way to enforce use of a particular encryption algorithm (or even verify it was used...) In this case, the text describing AES as the "default" algorithm should be replaced with text recommending the use of AES, and 8.1 in security considerations should get some text explaining why it would be bad for the mobile node to select a weak algorithm.
      If I am wrong, and the home agent (or any other participant) also computes the encrypted home address we have a different problem. To have crypto agility we need a mechanism to communicate which symmetric algorithm is in use, and I didn't see any evidence of that in the new messages/payloads.
      Comment [2009-06-18]:
      Also in section 5.1, in the third message: should destination be "home agent" instead of "home address"?

    Telechat:

3.3.2 Returning Items

  1. Unintended Consequence of two NAT deployments with Overlapping Address Space (Informational)
    draft-ford-behave-top-06
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-02]: I'm confused by the example in section 3.2.4. Does the example discuss hijacking inbound mail, outbound mail or IMAP/POP access?
      Does this sentence from the second paragraph in 3.2.4 refer to NAT-2 in figure 1.1:
      "Ideally, ISPs should not use NAT devices to provide connectivity to their customers."
      LSNs (large scale NATs) seem to be an inevitable example of deployments like NAT-2. Perhaps section 3.2.4 could be expanded to explain how NAT-2 and NAT-3 would be configured to accommodate inbound mail to a mail server on Host G?
    2. Cullen Jennings: Discuss [2009-06-03]: I think document is confused about how two different interfaces can have the same IP and how that works. The advice about split VPN goes strongly against what the RAI area generally recommends. The advice about blocking IP that mach the IP of of the access router is really bad and goes against what pretty much every VPN product I could find to test actually does. I would like to talk on the call about if this draft is harmful for VPN deployments and if it should be DNP.

    Telechat:

  2. Adding Acknowledgement Congestion Control to TCP (Informational)
    draft-floyd-tcpm-ackcc-05
    Token: Lars Eggert
    Extracted from Balloting:
    1. Adrian Farrel: Discuss [2009-06-18]:
      In section 2.1
      "Only the following values MUST be specified for structure-agnostic emulation (see [RFC4553]): ..."
      I cannot pare this. Does the "MUST" apply to future specifications? I.e., is it an instruction to IANA? Or are you trying to say...
      "For structure-agnostic emulation, this parameter MUST be set to one of the following values."
      Comment [2009-06-18]:
      You have some non-2119 language that may need attention. For example, in Section 2.2
      "PT is the payload type expected in the RTP header. A value of zero indicates that the receiver shall not check payload type to detect malformed packets."
    2. Cullen Jennings: Discuss [2009-06-17]: I can live with the IESG note as is, but after reading this draft, I think it might be more appropriate to change the IESG note to something along lines of:
      "The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. See RFC 3932 for more information."

    Telechat:

1304 EDT break

1311 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. STORage Maintenance (storm)
    Token: Lars

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Site Multihoming by IPv6 Intermediation (shim6)
    Token: Jari

    Telechat:

  2. Diameter Maintenance and Extensions (dime)
    Token: Dan

    Telechat:

  3. Integrated Security Model for SNMP (isms)
    Token: Pasi

    Telechat:

4.2.2 Proposed for Approval

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

    Telechat:

  2. Geographic Location/Privacy (geopriv)
    Token: Cullen

    Telechat:

5. IAB News We can use

  1. Amy: neither Dave or Olaf
  2. Lars: wasn't on last call, planning network neutrality talk for plenary on mail-list, two speakers (legal and protocol issues); RFCed process; discussing DNS stuff
  3. Russ: calls have gone out for RFCed and Independent Stream editor

6. Management Issues

  1. NomCom Requirements (Russ Housley)

    Telechat:

  2. Review of application/mp21 Media Type (Alexey Melnikov)

    Telechat:

  3. Request early allocation approval for 0x096D Pseudowire Switching TLV [IANA #245727] (Michelle Cotton)

    Telechat:

  4. Approval of liaison statement on Y.flowstate to ITU-T SG11 (Lars Eggert)

    Telechat:

  5. Reserving/Holding value in dns-parameters [IANA #206574] (Michelle Cotton)

    Telechat:

7. Agenda Working Group News

1411 EDT Adjourned

Valid HTML 4.01 Strict