IESG Narrative Minutes

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

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

Corrections from: Cullen, Magnus

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. Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (Proposed Standard)
    draft-ietf-behave-turn-13
    Token: Magnus Westerlund Was deferred by Ron Bonica on 2009-03-11
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-04-07]: supporting Lars' and Russ's DISCUSSES
    2. Lars Eggert: Discuss [2009-04-07]: Because TURN doesn't translate the ICMP messages necessary for PMTU discovery, persistent fragmentation can occur. When we discussed this in the WG, I thought we had come to an agreement that the document should say that TURN is NOT RECOMMENDED for applications that exchange UDP packets larger than the minimum PMTU (500-odd bytes), unless they implement RFC4821.
    3. Adrian Farrel: Comment [2009-04-02]: I understand that other-then-UDP mechanisms for server-peer communications will follow, but I find it confusing that the Introduction discusses client-server TCP and TLS services since the client is presumably actually interested in client-peer delivery. Also that Figure 1 shows a peer behind a NAT and the text comments that some firewalls block UDP entirely.
      Would it be helpful to draw out more clearly what deployments and service functions are not possible with the UDP-only variety of TURN? (There is some discussion in section 2.4 of the security of the server-peer data being the protected through encryption or similar.)
    4. Russ Housley: Discuss [2009-04-04]: The IAB Considerations in RFC 3424 have not been changed, and it is clear to me that TURN has an indefinite lifetime. So, the first two IAB UNSAF criteria cannot realistically be satisfied. I do not want to delay the document, but I do think it should include a recognition of this conflict. I'm happy with an IESG note or text in the body of the document.
    5. Cullen Jennings: Discuss [2009-04-08]: Refresh's, allocations, permission, and channel bindings request MUST be authenticated to meet the security requirements.
      The lack of authentication on the redirect response makes it trivial to DDOS any set of clients trying to use a STUN server by just redirecting them to a server that does not work.
      Section 10.3 needs to say the server MUST discard the packet if there is no permission to meet the security requirements.
      Comment [2009-04-08]: Seems weird that we can negotiate lifetimes of allocations but not permissions or channels bindings. Why?
      Padding up the Channel Data messages over TCP is a waste of bandwidth - why is it needed?
    6. Alexey Melnikov: Comment [2009-03-28]: In Section 6.2:
      5. The server checks if the request contains an EVEN-PORT attribute. If yes, then the server checks that it satisfy the request.
      Missing word: ... that it *can* satisfy ...
    7. Tim Polk: Discuss [2009-04-07]: As I understand it, this specification mandates client support for STUN authentication, but this is not a MUST implement for TURN servers. The specification provides good reasons to include that support in servers (section 2.2, "since relaying data may require lots of bandwidth..."), the protocol *requires* authentication to install or refresh permissions (section 2), and authentication is identified as the solution for several threats in the security considerations. This makes me wonder if STUN authentication shouldn't be a MUST implement for servers.
      Are there significant deployment scenarios where a TURN server could be deployed safely, and meet all the operational requirements without supporting authentication? If not, I would suggest making authentication a MUST implement for servers. (If significant scenarios exist where authentication would not be used, then I would leave things as is...)
      Comment [2009-04-07]:
      section 2, next-to-last paragraph s/to application data/to send application data/
      section 2.4, para 3: s/an XOR-PEER-ADDRESS attribute specify/an XOR-PEER-ADDRESS attribute specifying/
    8. Robert Sparks: Discuss [2009-04-06]:
      • In section 11.2, I'm not finding where it's explicitly specified what the lifetime of a Permission established by a ChannelBind is. I think both the server and client are expected to use the lifetime of the ChannelBind as the lifetime of the Permission, but this should be explicitly stated.
      • The text defining how the lifetimes of permissions and allocations are established say to use either the value requested by the client, or the defaul lifetime (see the bottom of page 25, top of page 26 for example). The example shows the server choosing a value (20 minutes) between those. Was the intent of the normative text to allow the server to choose any value between the default and requested value, or only the endpoints?
      • I think there is an unintended problem in the way the processing for Allocate requests is spelled out on pages 23 and 24. As written, a request that contains both a RESERVATION-TOKEN and an EVEN-PORT attribute that the server couldn't satisfy, step 5 will cause a 508 error (which will lead to the client trying the same request again). The intended check to reject this with a 400 doesn't occur until step 6.
      • Should the text in 17.2.3 say that the TURN server will never accept traffic from a peer which the client has not installed a permission for, rather than which the client has not yet contacted?

      Comment [2009-04-06]: There are several invariant times called out in this document without motivation (default lifetimes MUST be 300 seconds, clients SHOULD wait at least one minute before doing some things and MUST wait 5 minutes before doing others). It would be nice to let the implementors know, if possible, why these values were chosen.
      The text in the NOTE on page 25 will not age well after this is published as an RFC

    Telechat:

  2. LDP Capabilities (Proposed Standard)
    draft-ietf-mpls-ldp-capabilities-03
    Token: Ross Callon
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-04-09]: The name of the U bit would have been nice to have in the doc.
      I agree with the issues other people have raised.
    2. Ron Bonica:Comment [2009-04-07]: I think that this DISCUSS can be cleared up with an RFC editor note:
      In Section 3, you should say that the U bit tells a LDP speaker how to behave if it does not support this capability (u stands for unsupported?)
      In Section 3, why does the F-bit exist if it must always be set to 0? If it might be set to 1 at some future time, shouldn't you tell us what to do when that happens?
      In Section 3.1, you might want to enumerate the exiting protocol extensions that could act as capability TLVs.
    3. Lisa Dusseault: Comment [2009-04-07]: The advice on future documents that actually name and define capabilities, seems to be incomplete. Perhaps its clear to the authors, but I don't understand which IANA registry future capabilities would be listed in.
      It would also be good to advise those future capabilities defining documents, to specify whether the capability is even appropriate for being advertised mid-session. Some capabilities might require dropping a session.
    4. Lars Eggert: Comment [2009-04-06]: Should this document update RFC5036; i.e., is this something that should be considered must-implement for LDP from now on?
    5. Adrian Farrel: Discuss [2009-04-02]: Hopefully this can be cleared with a simple exchange of email.
      In section 3.1 you state that the "FT Session TLV" fomr RFC 3479 can be treated as a Capability Parameter. Yest the FT Session TLV already assigns meaning to the first bit of the fifth octet (the R-bit in section 8.2 of RFC 3479) and this seems to conflict in meaning with the S-bit in the Capablity Parameter TLV you define in section 3.
      I suspect that this may be resolved by some clarification of "play the role of."
      Comment [2009-04-02]: Since the intention is to publish an RFC that will be current, it would be advisable to remove present tense text from the Abstract that will actually refer to the past. Thus, suggest you delete...
      "At present, LDP has no mechanism for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established."
      There is similar text in the Introduction that I would also recommend you to delete.
      -----
      It would be wise to include a reference (informative) to draft-ietf-mpls-mpls-and-gmpls-security-framework in section 11

    Telechat:

  3. Clarifications and Extensions to the GSS-API for the Use of Channel Bindings (Proposed Standard)
    draft-ietf-kitten-gssapi-channel-bindings-07
    Token: Tim Polk Note: proto writeup received...
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-04-06]: Based on the response from the author to Brian Carpenter's Gen-ART Review, I was expecting this paragraph to be revised:
      "Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), then the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above, rather than some encoding of GSS-CHANNEL-BINDINGS."
      The expected update would be something like this:
      "Where the language binding of the GSS-API model's channel bindings is a single OCTET STRING (or the language's equivalent), then the implementation SHOULD assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS shown above."
    2. Cullen Jennings: Comment [2009-04-06]: Support Lars discuss
    3. Alexey Melnikov (recused): Comment [2009-03-26]: I was a WG chair for Kitten at the time of the publication request and were involved in discussions about it.

    Telechat:

  4. Softwire Security Analysis and Requirements (Proposed Standard)
    draft-ietf-softwire-security-requirements-07
    Token: Ralph Droms Was deferred by Pasi Eronen on 2009-03-12
    Extracted from Balloting:
    1. Ralph Droms: Discuss [2009-04-07]: Has this document been reviewed by the Security Directorate?
      The attack threat scenarios list in sections 3.3 and 4.3 mostly describe attacks on individual packets or flows; e.g.:
      3.3: 1. An adversary may try to discover identities by snooping data packets.
      4.3: 1. An adversary may try to discover confidential information by sniffing softwire packets.
      Why is the scenario in 3.4 limited to just identities and not other confidential information? I would expect that these packet attacks would be the same in both hub-and-spoke and mesh scenarios.
      At the same time, I would expect there would be different attack scenarios based on the different security and trust models; for example, in the message exchange between the visited and home AAA services in the case of the hub-and-spoke scenario.
    2. Lars Eggert: Comment [2009-03-11]: WG history or details are not typically relevant for RFCs. Rephrase the introduction to make this about the technology rather than the WG.
    3. Pasi Eronen: Discuss [2009-04-08]: I have reviewed draft-ietf-softwire-security-requirements-07, and have a couple of concerns that I'd like to discuss before recommending approval of the document:
      - Section 3 needs to be clearer that there are *two* different (and incompatible) solutions for securing L2TPv2 with IPsec (see new text in Section 10 of hs-framework-l2tpv2-12). Some of the details differ, and the MUSTs etc. need to be aligned with hs-framework-l2tpv2.
      - Sections 3.5.4.1 and 3.5.4.2: To me it seems the SPD and PAD entries for IPv6-over-IPv4 and IPv4-over-IPv6 cases should be identical (except replacing IPv4 addresses with IPv6 and vice versa) -- but they're not. Why? (to me the entries in 3.5.4.1 look more correct than 3.5.4.2 -- at least the SC PAD entry in 3.5.4.2 looks unrealistic, since usually the SC won't know SI_address beforehand.)
      - Section 4.4.2: It seems this isn't fully aligned with softwire-encaps-ipsec, since it doesn't describe the use-public-key-crypto-without-PKI approach.
      - Section 4.2.2, 3rd paragraph: since softwires are created dynamically by BGP, the paragraph should clarify that "pre-shared key" here really means "group key" (same key in all routers), not pairwise shared keys.
    4. Russ Housley: Discuss [2009-04-04]: After the Gen-ART Review by Christian Vogt, the authors agreed to make changes to the document. These changes have not appeared yet.
    5. Tim Polk: Discuss [2009-04-09]: This document has a number of issues that should be addressed efore publication.
      #1 the document does not clearly explain the scope or goal, or what form the follow-on work will take...
      #2 upper and lower case musts and shoulds are used seemingly interchangably. Sorting out the requirements is very difficult imho.
      #3 Figure is mislabeled, I think... since the supporting text is all about the SI-SC authentication model for hubs and spokes
      #4 Section 3.4 talks about the "Softwire security protocol" but earlier text implied no mandatory to implement protocol would be specified. Are these requirements for softwires, or for a new protocol?
      [Note: I apologize for the brief nature of this discus. I will add comments later in the week to help ensure these issues are actionable...]

    Telechat:

  5. Network Time Protocol Version 4 Protocol And Algorithms Specification (Proposed Standard)
    draft-ietf-ntp-ntpv4-proto-11
    Token: Ralph Droms Was deferred by Cullen Jennings on 2009-03-08
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-04-07]: I'm fine with the specification itself, but the source code in Appendix A needs work if it is to be included: functions are being duplicated (root_dist), types are wrongly defined (tstamp needs to be "long long" for 64-bit), headers aren't being included (memset), == is used for an assignment, more syntax errors (comments being incorrectly closed), etc.
      Given that even the syntax of this code is wrong, what is the assurance that the semantics are correct?
    2. Pasi Eronen: Discuss [2009-04-09]: I have reviewed draft-ietf-ntp-ntpv4-proto-11, and have a couple of concerns that I'd like to discuss before recommending approval of the document:
      - The document says SNTPv4 (RFC 4330) is a subset of NTPv4, but the text about MAC calculation isn't aligned. RFC 4330 says MAC is calculated is specified in RFC 1305, Appendix C (DES in CBC-MAC mode), but this draft uses MD5 (in secret-prefix mode). The text also says NTPv4 is backwards-compatible with NTPv3 -- but that doesn't seem to be the case for MACs... Could you clarify?
      - Section 7.3 should be a bit clearer on how the MAC is calculated (e.g. what data is covered, and where the key goes). Appendix A.2 says it's secret-prefix mode (prepend key to data), but e.g. is the Key Identifier field included in the data?
      - Section 7.3: it seems both the Key Identifier and Message Digest fields can be omitted in some circumstances? If that's the case, this should be mentioned in Section 7.3.
      - Section 9.2 talks about "with a MAC consisting of four octets of zeros". Does this mean "Key Identifier with value zero, and omitting the Message Digest field?"
      - The security considerations text is very thin, and doesn't really explain what the threats are (e.g. what an attacker might want to accomplish). It looks like Section 2 of draft-ietf-ntp-autokey has text about this. Perhaps some of that text should be moved here?
      - The security considerations section probably needs a paragraph explaining why we're publishing a specification in 2009 that uses a broken hash function (MD5) with a broken-with-any-hash MAC construction (secret-prefix), and doesn't provide any algorithm agility. (Something like "The goal of this specification is to document existing widely deployed..; adding new features (including new security features) is beyond the scope")
    3. Adrian Farrel: Comment [2009-04-05]: In support of Alexey Melnikov's Discuss, I would like to see more description of the backward compatibility mentioned in the Abstract, but not described anywhere in detail. What happens if an NTPv3 client talks to an NTPv4 server, or an NTPv4 client communicates with an NTPv5 server?
      The 128-bit NTP Date Format in Figure 3 appears to show 160 bits because the Fraction field is shown as occupying three lines.
    4. Russ Housley: Discuss [2009-04-04]: Brian Carpenter provided a Gen-ART Review on 2009-03-09, and it has not received any response. While the document is in good shape, some issues were reported. At a minimum, the following comments deserve a response (although it would be much better to respond to the entire review):
      • There is a summary in the Introduction of the new features compared to NTPv3 and SNTPv4. However, it would be highly useful for implementors to have a detailed list of the technical additions and changes.
      • In Fig. 9 (leap indicator values) there is an 'alarm condition' value, but Brian didn't find a description of what should be done after receiving this indicator.
      • Some tables of code values (e.g. Figs. 9 - 11, 22) that are *not* to be IANA-maintained. That implies that any updates would need to update the protocol document. Is that intended?
      • [ref3] appears to be required reading if somebody wants to implement Autokey. If so, it needs to be a normative reference. Alternatively, a reference to draft-ietf-ntp-autokey-04 could be used. Either way, if this is a normative reference, then the result is a downref.
      • Is RFC 1345 really a normative reference? If so, it is a downref.
    5. Cullen Jennings: Discuss [2009-04-06]: I think the source code needs the appropriate license attached.
    6. Alexey Melnikov: Discuss [2009-03-28]: I think this is an important document and I expect to clear my DISCUSS as soon as I get some clarifications.
      I would like to better understand compatibility between different versions of NTP. The Introduction section says:
      "While certain minor changes have been made in some protocol header fields, these do not affect the interoperability between NTPv4 and previous versions of NTP and SNTP."
      Does this mean that all versions use the same packet format (apart from adding some new fields to the end of the packet in later versions)?
      Section 9.2 says: "Format checks require correct field length and alignment, acceptable version number (1-4) and correct extension field syntax, if present."
      Is a NTPv4 client/server expected to support earlier versions of NTP?
      Comment [2009-03-28]: It would have been nice if terms like "association mode" are explained at the beginning of section 3 (or earlier).
      On page 22:
      "Reference ID (refid): ... reserved for unregistered experimentation and developent."
      typo: development
      In the IANA Considerations section: FCFS acronym should be expanded.
      RFC 2434 was replaced by RFC 5226 (this can be fixed by RFC Editor).
      A section listing detailed changes since the obsoleted RFCs would be helpful. I let other ADs hold a DISCUSS on this, if they feel this is appropriate.
    7. Tim Polk: Discuss [2009-04-08]: This is a very significant update to RFC 1305, and I am happy to see it nearing publication. There are a couple of issues I would like to see addressed, though.
      1. Richard Barnes' secdir review (3/10/09) raised several important issues, but to my knowledge there has been no response.
      2. The security considerations section does not provide the information needed by readers, in my opinion. I found much more helpful information in Section 2 of ntp-autokey (starting in paragraph 5 "the assumed goal of the intruder is...", and suggest replicating some of that material here. In particular, the description of the built-in defense mechanisms and the assumptions was helpful. (Some of the assumptions may not apply here, but most appear to apply...)
        The reference to the Bellovin-Rescorla paper in the text about MD5 (first paragraph of the existing security considerations section doesn't really help the reader understand if the current digest mechanism is worth using or not. Is this a reason to use Autokey? Is it irrelevant for most implementations?
      3. NTPv4 lacks algorithm agility with respect to the MAC algorithm, and the sole algorithm is MD5. The mac is an ntp-specific construction rather than the standard hmac. (This issue was also raised in Richard Barnes' secdir review.) I would like to know if the wg considered changing to a stronger hash algorithm or to the conventional hmac (regardless of hash algorithm).
      4. I am concerned about discrepancies between the body text and the appendices. I believe clear text is needed stating the code fragments in the appendix are strictly informative, and the body text takes precedence and is the standard for compliance. text takes precedence in any dicscrepancy,
    8. Robert Sparks: Discuss [2009-04-07]: This is a discuss-discuss.
      It's not obvious that there is enough specification in the body of the document to implement this protocol if the appendix were deleted. Is it the intent that the appendix is only informative and not essential for implementation? If so, are there members of the community familiar with this protocol that have reviewed the document from this perspective and found it implementable without the appendix as a guide?
      Comment [2009-04-07]: Concur with Russ' concern with [ref3]
    9. Magnus Westerlund: Comment [2009-04-08]:
      Section 3: 
                     +-------------------+--------------+-------------+

               |  Association Mode | Assoc. Mode  | Packet Mode |
               +-------------------+--------------+-------------+
               | Symmetric Active  |       1      | 1 or 2      |
               | Symmetric Passive |       2      | 1           |
               | Client            |       3      | 4           |
               | Server            |       4      | 3           |
               | Broadcast Server  |       5      | 5           |
               | Broadcast Client  |       6      | N/A         |
               +-------------------+--------------+-------------+

                  Figure 1: Association and Packet Modes

      In the client/server variant a persistent client sends client (mode 3) packets to a server, which returns server (mode 4) packets. Servers provide synchronization to one or more clients, but do not accept synchronization from them.
      There appears to be some confusion around which mode is meant here. A peer in Client mode is according to the table sending packets in mode 4 but the text says 3. Please disambigify this.
      Section 16: "Following the policies outlined in [RFC2434], new values are to be defined by IETF consensus."
      Old reference needs to be udpated to RFC 5226.

    Telechat:

  6. Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) (Proposed Standard)
    draft-ietf-ntp-ntpv4-mib-05
    Token: Ralph Droms Was deferred by Cullen Jennings on 2009-03-08
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-04-07]: Supporting Dan's discuss
    2. Adrian Farrel: Discuss [2009-04-04]:
      1. The document does not state which track this is on. I can find nothing in the write-up either.
      2. http://www.ops.ietf.org/mib-security.html describes the security text that should be present. The security section seems particularly light.
      3. The copyright appears to be missing from within the MIB module.
      4. In general, it seems odd to have DisplayString and Integer variants of many objects. It causes the implementer to have to handle the case when the objects do not agree.
        In some cases, this is particluarly bad. For example, why is ntpEntStatusCurrentMode a DisplayString with a well-known set of legitimate values? Surely this gives rise to potential discrepencies. Doesn't ntpEntStatusCurrentModeVal give you everything you need?
      5. Several read-only objects have DEFVAL clauses. This has no meaning!
      6. Shouldn't ntpEntStatusEntityUptime use a TimeStamp syntax?

      Comment [2009-04-04]:
      1. The MIB module guidelines say that you should include boilerplate for RFC 2119. However, there is no such language used (which is a bit surprising) so perhaps the boilerplate is not needed.
      2. It would be nice if the modules included by the IMPORTS clause were identified by RFC name (in comments) and included as normative references.
      3. I think the longish change log comment should be removed before publication as an RFC.
      4. You should update the REVISION clause so that the published RFC is the first revision of this MIB module.
      5. Nits
        Abstract s/independant/independent/; s/Internet draft/document/
      6. Instead of stating "Ref: draft-ietf-ntp-ntpv4-proto-06" within a DESCRIPTION clause, you should include a REFERENCE clause.
        It might be good if you included a request to the RFC Editor so that REFERENCE clauses citing draft-ietf-ntp-ntpv4-proto-06 will be updated to indicate the RFC number of that work which we assume will go forward in lock-step.
    3. Russ Housley: Discuss [2009-04-04]: The following comment was raised by Ben Campbell in his Gen-ART Review, and no response has been received. Please respond to the comment. Ben said:
      The comment says "shows the resolution based on 1 second, e.g. "1ms" translates to 1000". That confused me at first, since 1ms != 1000 s. I suspect you are talking about the number of divisions in a second, in which 1000 would make sense--but I didn't immediately get that from the text.
      Comment [2009-04-04]: Ben Campbell got an "unknown address error" for chelliot@cisco.com when he sent his Gen-ART Review. Please make sure all the author addresses are correct prior to publication.
    4. Cullen Jennings: Discuss [2009-04-06]: MIB needs the new licenses text.
      Comment [2009-04-06]: Support Discuss from several other ADs.
    5. Tim Polk: Discuss [2009-04-07]: As noted, by several others, the guidelines in http://www.ops.ietf.org/mib-security.html were not used to develop the security considerations section. I believe there are plausible attacks based on changes to the notification values, and some of the read-only information may be useful in designing a successful attack (e.g., product name and software version). (It is less clear to me if the objects in sections 2 and 3, "Current NTP status" and "The status of all currently mobilized associations" are of utility to an attacker.)
      These issues should be documented consistent with the guidelines referenced above.
    6. Dan Romascanu: Discuss [2009-04-05]: The DISCUSS below is based in part on the MIB Doctor review performed by Bert Wijnen. This review was sent to the NTP WG list, but was never answered and the document was not revised.
      1. The MIB module does not compile clean...
      2. There are two writable objects for which there is no text in the DESCRIPTION clauses about expected persistency behaviour
      3. There are Counter32 objects with no test in the DESCRIPTION clauses about possible discontinuities and which timer object would indicate such...
      4. There is a lot of commented text in the MIB module which would rather be included in the DESCRIPTION clauses of the objects (the information that is contained seems usefeul)
      5. The design of duplicate MIB objects with similar semantics in both text and numerical formats is broken...
      6. ntpEntSoftName, ntpEntSoftwareVersion duplicate functionality from the Entity MIB
      7. The whole list of REVISION clauses is useless. Normally we only have a single revision clause at RFC publication time. Not a list of revisions that took place during I-D revisions.
      8. The Copyright statement in the DESCRIPTION clause of the MODULE_IDENTITY is missing
      9. The statement that this revision of the document is published as RFC xxxx (xxxx to be filled in by RFC-editor)is missing
      10. There are severa objects with a SYNTAX of DisplayString. I would like to point out "note 2" on web page http://www.ops.ietf.org/mib-common-tcs.html
        Note 2. DisplayString does not support internationalized text...
      11. Instead of 
             ntpEntNotifPrefix  OBJECT IDENTIFIER ::= { ntpSnmpMIBObjects 6 }
     ...
     ntpEntNotifications OBJECT IDENTIFIER ::= { ntpEntNotifPrefix 0 }
        I propose/suggest to do "ntpEntNotifications OBJECT IDENTIFIER ::= { ntpSnmpMIB 0 }"
        This makes it more inline with the current practice in MIB modules. Also makes the OIDs of notifications shorter
      12. I strongly recommend to use the MIB structure as per RFC4181, which suggests that you would replace "ntpEntConformance OBJECT IDENTIFIER ::= { ntpSnmpMIB 6 }" with "ntpEntConformance OBJECT IDENTIFIER ::= { ntpSnmpMIB 2 }"
      13. There are OBJECT-GROUP definitions like "ntpEntObjectsGroup1 OBJECT-GROUP..."...
        Text about "should implement" or "optional" or such is NOT supposed to be in an OBJECT-GROUP DESCRIPTION clause. The OBJECT-GROUP is only meant to group objects logically together. If such a group is mandatory or optional is something that is expressed via MANDATORY-GROUPS or via the GROUP clauses in the MODULE-COMPLIANCE.
        As another example "ntpEntObjectsGroup2 OBJECT-GROUP..."... So that is a conflict in the MIB-Module.
      14. Several references/citations look like: "NtpDateTime ::= TEXTUAL-CONVENTION..."
        I suggest that the pointer to Ref: draft-ietf-ntp-ntpv4-proto-06 is changed to Ref: RFC yyyy...
        In genreal though, it is better to use the REFERENCE clause. So it would be something like
        REFERENCE "Network Time Protocol Version 4 Protocol And Algorithms Specification, sect 6, RFC yyyy"
      15. It seems to me that for something like this: "ntpEntStatusEntityUptime OBJECT-TYPE..." It's better to use UNITS clauses.
        Same for all Counter32 objects - defining UNITS clauses would be very helpful.
      16. DEFVAL does not make sense for read-only objects.
      17. "ntpEntStatPktModeTable OBJECT-TYPE..."
        How comes that the same DESCRIPTION clause is defined for each of these?
      18. "ntpAssocAddressType OBJECT-TYPE..."
        RFC4001 states that the use of InetAddress SYNTAX, MUST have a DESCRIPTION clause that explains/states which object of SYNTAX InetAddressType controls the format of the InetAddress object. It is most probably ntpAssocAddressType but it would be good to state so.
        Besides, if you are sure that this ALWAYS only applies to IPv4 and IPv6, then it is better to do as follows: 
            ntpAssocAddressType OBJECT-TYPE
       SYNTAX      InetAddressType { ipv4, ipv6 }

   ntpAssocAddress OBJECT-TYPE
       SYNTAX      InetAddress SIZE(4|16)

        You must check if you also want to use Zoned addressed, because then that must be added too.
        If, at the other hand, other values than ipv4/ipv6 are possible (maybe in the future?) then it might be better to put the "minimum support for ipv4/ipv6 requirement in the MODULE-COMPLIANCE via an OBJECT and SYNTAX clause.
      19. There are some 8 notifications. Is there a risk that too many get generated at any point in time, such that it would flood the network and/or overload a NMS ??
        It would be good to add some text about the expected max notification rates and/or add a throtle or an enable/disable switch.
      20. It seems that RFC4001 is missing as a normative reference.
      21. draft-ietf-ntp-ntpv4-proto-11 (version 4 of NTP)should also be a normative reference
      22. The security section is not according to the guidelines provided at http://www.ops.ietf.org/mib-security.html
    7. Robert Sparks: Comment [2009-04-07]: Support Adrian's and Dan's discusses

    Telechat:

  7. RSVP Extensions for Path Key Support (Proposed Standard)
    draft-ietf-ccamp-path-key-ero-04
    Token: Ross Callon
    Extracted from Balloting:
    1. Adrian Farrel (recused): Comment [2009-04-05]: I am currently still working group chair for this I-D. I am also a co-author.

    Telechat:

  8. Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization (Proposed Standard)
    draft-ietf-pce-global-concurrent-optimization-10
    IPR: HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to draft-bernstein-ccamp-wson-signaling-03, draft-ietf-pce-global-concurrent-optimization-05, and draft-tsou-pcn-racf-applic-01
    Token: Ross Callon
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2009-04-07]: I have reviewed draft-ietf-pce-global-concurrent-optimization-10. Overall, the document looks good, but I have one question:
      In Section 5.5, the text says the GC object has 24 reserved bits, but these are not shown in Figure 3. Which is correct?
      Comment [2009-04-07]: Charlie Kaufman's SecDir review included several editorial nits that should be fixed (but this can happen during RFC editor processing).
    2. Adrian Farrel (recused): Comment [2009-04-05]: I am currently still working group chair for PCE. I also contributed significantly to this I-D.
    3. Robert Sparks: Comment [2009-04-07]: It's probably worth checking that the update to <svec-list> didn't get out of step with the other -pce- documents (similar to -pce-of- while in genart). I don't think there's a problem, but someone more familiar with the whole set with me should look.
      If MU and mU are intended to be integers that can only be between 0 and 100, the text would benefit from explicitly stating that. (or is having an MU of 255% ok?)

    Telechat:

2.1.2 Returning Items

  1. GIST: General Internet Signalling Transport (Proposed Standard)
    draft-ietf-nsis-ntlp-19
    Token: Magnus Westerlund Note: Please check your comment field so that it doesn't contain old text! RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation. Pleas also include some motivation behind your decision.
    Extracted from Balloting:
    1. Ron Bonica: Comment [2008-12-04]: Let's discuss this in the call. I seem to remember an agreement with the authors the last time they attended an informal call, but I am not sure that the terms of that agreement have been met in v17.
    2. Ross Callon: Comment [2009-04-08]: I am leaving my vote as "abstain" because I still feel that this should be "experimental". I believe that my other discuss comments were addressed in a past update.
      To me this appears to have very substantial implications on routers, hosts, and other devices as well. Thus while there are some implementations, nonetheless for something with this wide an effect, I think that there also needs to be testing in reasonably sized networks before it moves from "experimental" to "proposed standard". I feel that there also needs to be a very substantial justification for why we need this as a standards track protocol (in addition to the existing signaling mechanisms that we have, such as RSVP and RSVP-TE).
    3. Brian Carpenter: Comment [2007-03-16]: ... I'm very doubtful about the real deployability of GIST; these extracts say why:...
    4. Lisa Dusseault: Comment [2008-12-10]: My position on this document is ABSTAIN because I do not feel it has the quality we expect on the standards track. I would move to NO-OBJ if it were Experimental.
    5. Lars Eggert: Comment [2008-03-26]: (empty)
    6. Pasi Eronen: Comment [2008-12-03]: The latest version no longer uses the Router Alert option, so it probably will not cause harm to the existing infrastructure.
      I do agree with Chris's comment that this is unlikely to be useful or deployed, but I am voting no objection because this is in the WG charter (however, if the WG charter was proposed today, I would probably not support it).
    7. Adrian Farrel: Discuss [2009-04-02]: This document has moved on a long way since I did the Routing Area review some years ago. Well done for that.
      1. (This point inherited with some modifications from Dave Ward)
        I feel that if this I-D were labeled as Experimental we could have moved forward long ago. Note that being Experimental is not an indictment of the protocol spec, but a statement about how important the protocol is and how disruptive it might be. A new IGP would certainly remain Experimental until it had been deployed successfully in the wider Internet and we had a deployment experience report. Conversely, if the protocol is intended only for deployment in "safe" situations such as walled gardens, we could move forward with a very clear statement in the Abstract and Introduction (as well, perhaps, as a dedicated section on the subject of deployment).
        The action to resolve this Discuss point is therefore one of three things:
        - make the document Experimental
        - include the deployment discussions
        - explain to me why neither of the above is necessary.
        It should be noted that resolving this point with either of the first two suggestions will close down my other Discusses.
      2. (This is a new point and so, because of the stage of the process, I will be willing to give way on it far more easily.)
        According to Section 7.1, the Query refresh is an important mechanism to trigger detection of reroute events so as to inform the signaling client that it should refresh the end-to-end state. Section 4.4.4 suggests that this refresh should default to 30 seconds and suggests a formula to decay this rate in the presence of congestion caused by a large number of sessions all needing to issue refreshes.
        I could not find any discussion of how fast the client really needs to find out about these events, and therefore how rapid the refresh process really needs to be. Can we guarantee that the decayed rate will always be fast enough? If so, why not start at the slower rate in all cases? If not, how will the protocol notify the client in time?
        It seems to me that the resolution of this Discuss may lie either in defining a "refresh reduction" technique such as was invented for RSVP in RFC 2961, or in requiring the source GIST node to inspect the RIB (as mentioned, but not made mandatory in Section 7.1).
      3. (This point inherited with some modifications from Dave Ward)
        I am not comfortable with the mechanism for detecting GIST packets at a GIST node. If I understand correctly, each IP packet for any destination must be examined as follows:
        - emaine IP payload
        -- if payload is UDP examine UDP port number
        --- if UDP port number is reserverd for GIST
        ---- apply a rate limit
        ----- check the first word of UDP payload is magick
        The first two checks must be made for all UDP traffic and the second check constitutes a form of deep inspection.
        Can this be done at line speed by a GIST-capable node? I am concerned that a GIST-capable node might become stressed by a large amount of non-GIST transit UDP traffic. This traffic might even be the flow that GIST is being used to support.
        Are you proposing that this check should be done in hardware on the GST-capable nodes? If not, how can you be sure that the slow path will be able to handle the pass-through data fast enough?
      4. (This is a new point and so, because of the stage of the process, I will be willing to give way on it far more easily.)
        Section 5 includes definitions of messages in a loose, but nevertheless formal, language. I see operands =, /, and []. There is also some assumption about ordering. The same syntax is used in the definition of some of the TLVs later in the section, where operands 0* and 1* are also used.
        I would like to see a formal definition (or a reference to a formal definition) of this language so that the message construciton is unambiguous.

      Comment [2009-04-02]:
      1. The Introduction contains...
        "This specification concentrates mainly on path-coupled signalling, controlling resources on network elements which are located on the path taken by a particular data flow, possibly including but not limited to the flow endpoints."
        This use of "mainly" begs the question: what else does it concentrate on?
      2. I think the reference to [13] should be moved to Informative to allow the I-D to go forward without being encumbered. Furthermore, the I-D is not named correctly in the reference.
      3. The use of square-bracket numbers in Figures 7, 8, and 9 is unfortunate as the references are all indicated in exactly that way. Would it be possible to use dome other form of bracket in the figures?
      4. A.5 has
        "Length (12 bits): Length has the units of 32-bit words, and measures the length of Value. If there is no Value, Length=0. If the Length is not consistent with the contents of the object, an "Object Value Error" message (Appendix A.4.4.10) with subcode 0 "Incorrect Length" MUST be returned and the message dropped."
        This is ambiguous! The only way to know the length of the contents of the object (i.e., the Value) is by examining the Length field. I think you mean, "If the Length is not consistent with the expected length of the Value field..."
      5. In 5.1 you have...
        "Messages with missing, duplicate or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9)."
        You are making a rod for your own backs! With this rule, a legacy GIST node will not accept a message with a new object on it, even if you are willing to let that node pass the unknown object on for processing at a further GIST node that does understand it.
        For example, in 5.2.2...
        "Currently, each object can occur at most once..."
        But give the rule above, you will find it hard to change this without upgrading every box in the network.
        But, in A.2.1 you save yourself with...
        "The leading two bits of the TLV header are used to signal the desired treatment for objects whose Type field is unknown at the receiver."
        Could you make these statements all consistent?
        Although I note...
        "The combination AB=11 is reserved. If a message is received containing an object with AB=11, it MUST be rejected with an "Object Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid Extensibility Flags")."
        ...means that AB=11 can never be used where there is a risk of hitting a legacy node.
      6. The reason for the use of the magick number is poorly explained. It appears to derive from a fear that other, non-GIST traffic will arrive on the GIST well-known UDP port. But what is this fear grounded upon? The document doesn't explain.
        If it is a fear of an attack, then the magick can also be inserted by the attacker, so it doesn't help. If it is a fear that the well-known UDP port is somehow already in use for some other traffic, then what traffic and what is the meaning of the IANA registry?
    8. Bill Fenner: Comment [2006-09-27]: No Further Objection. My concerns are adequately covered by several other DISCUSSes.
    9. Cullen Jennings: Discuss [2009-04-08]: I would be happy to see this specification published as experimental but I do not think it is "a reasonable basis on which to build the salient part of the Internet infrastructure". Some of the reasons why include:
      The change to using a port number to detect a GIST packet is, seems to me, a worse choice that RAO. It has most the problems of RAO plus some more. Routers can not process these slow path packets as anything like wire speed so they will need to make sure that the untrusted nodes can't introduce large numbers of these packets. The only way to do this is to filter at the trust boundary (as they do for RAO today). You can say they should only filter if both the port and magic number match but non gist aware equipment will not know how to filter on the special gist magic number and just filter on port. This will result in all traffic on whatever port is chosen for GIST begin blocked into the domain even if the traffic is not GIST traffic. For example, it could be voip packets - the document implies nothing should use the unregistered well known ports but that empirically does not seem to be true. Furthermore, giving ISP a solid reasons they need to block certain ports for network management considerations is exactly the wrong thing to preserver the type of internet the IETF generally desires. This will be a step backward for network transparency even if no one ever deploys a single GIST node.
      The advice for the routers seems to be to rate limit the packets GIST packets that are passed to the slow path. This seems like it will cause extremely confusing situations for the applications using GIST. For example, imagine that three GIST aware routers ore on the path, A, B, and C. And B is seeing a lot of GIST packets and just ignoring half of them. Some of the times when a GIST path will look like A,B,C while other times it will be just A,C. It does not seem like there is a way to discover or reliably deal with the non deterministic behavior of GIST node that is ignoring some but not all GIST packets.
      As discussed in section 8.2, the authentication has no idea of who is the correct party to connect to. Given this I don't see how TLS can provide integrity or confidentiality as described in 8.1
      Comment [2009-04-08]: (empty)
    10. Alexey Melnikov: Discuss [2009-03-30]: I found ABNF for Stack-Proposal to be incorrect (or at least confusing). Section 5.2.2 says:
      "Stack-Proposal: This field contains information about which combinations of transport and security protocols are available for use in messaging associations, and is also discussed further in Section 5.7."
      "Stack-Proposal = 1*stack-profile"
      "stack-profile = 1*protocol-layer"
      This is ambiguous: how does one can find out where one <stack-profile> ends and another begins (there are no delimiters between <stack-profile>, no field specifying how many of them, or any other type of framing)?
      One way to fix this part of my DISCUSS is to define ABNF to match Appendix A.3.4. Alternatively you need to at least add ABNF comments explaining that some fields are omitted (e.g. number of <stack-profile>) with pointers to sections where they are defined.
      protocol-layer is not defined anywhere, so ABNF is also incomplete.
      Then Section 5.7.1 says:
      "A Stack-Proposal object is simply a list of profiles; each profile is a sequence of MA-Protocol-IDs. A profile lists the protocols in 'top to bottom' order (e.g. TLS over TCP)."
      It is still not clear how it is possible to find out where a profile ends.
      Then Appendix A.3.4 says: 
         Type:  Stack-Proposal

   Length:  Variable (depends on number of profiles and size of each
      profile)


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Prof-Count   |     Reserved                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    Profile 1                                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    Profile N                                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Prof-Count (8 bits): The number of profiles listed. MUST be > 0.

   Each profile is itself a sequence of protocol layers, and the profile
   is formatted as a list as follows:

   o  The first byte is a count of the number of layers in the profile.
      MUST be > 0.

   o  This is followed by a sequence of 1-byte MA-Protocol-IDs as
      described in Section 5.7.

      So my understanding is that a Stack-Proposal is stored as a TLV object. What about each Profile? Are they stored as TLV objects as well?
      In multiple places: you need to clarify how port numbers are encoded on the wire (I assume they all in "network byte order").
      Comment [2009-03-30]: This is not a type of document I would wish a new AD to read for the first IESG telechat.
    11. Chris Newman: Comment [2007-04-12]: This document is so long and complex that I consider it highly unlikely it will deploy. As a result I am not concerned it will cause harm to the infrastructure. Because the WG delivered on its charter item I will vote no objection. Were this an individual submission, I would probably abstain.
    12. Tim Polk: Comment [2008-03-27]: I have a vaguely uneasy feeling on this document. Perhaps it is the consequence of trying to consume RFCs 4080, 4081, and the state machine document as well as gist in rather short order, but the complexity seems to be substantial. I am joining the ABSTAINs for now, but could change that position based on the discussion on today's telechat. Specifically, I could change my position if convinced this is both implementable and not dangerous to the Internet.
      If I do change my position, I would move to DISCUSS to address the following issue.
      Support for TLS is required, but different modes may be selected (e.g., different ciphersuites and authentication mechanisms). These changes significantly impact the security provided (and as a result, the degree to which the requirements in 4081 are met.)
      The security considerations section should elaborate on the impact of server-only vs. mutually authenticated TLS, as well as alternative authentication procedures, with respect to the various requirements.
    13. Robert Sparks: Discuss [2009-04-08]: Reviewing this version of the document (19), I share the concern that been expressed about the general deployability of this mechanism, and would be more comfortable with an experimental status or more explicit scoping of the expected applicability to areas where deployment is better understood.
    14. David Ward:Discuss [2008-12-04]: The updated sections from our last conversation are not quite complete. This draft: http://www.ietf.org/internet-drafts/draft-hancock-nsis-gist-rao-00.txt arrived in due to our conversation and is not referenced but, this document: http://tools.ietf.org/html/draft-nsis-ext-00 is in 5.3.2.5. Unfort we should not reference such new material in a PS and it has to be removed or the document has to delay until both these drafts move to the IESG. Overall, 5.3.2.5 may need to be removed as it is forward looking and causes much confusion.
      Also, of great concern in 5.3.2.3;
      "Within the network, there may be packets using the GIST UDP port but which are not in fact GIST traffic."
      and then
      "Q-mode packets carry the same magic number as other D-mode packets (see Section 5.3.1). A Q-mode packet intercepted within the network which does not match both the UDP destination port and the magic number MUST be forwarded transparently at the IP layer""
      This means that my filter has to inspect beyond the port and look for your magic number. This is akin to deep-packet-inspection for GIST packets. This is pretty much a non-starter.
      Later:
      "This specification allocates the following codepoints in existing registries:"
      "Well-known UDP port XXX as the destination port for Q-mode encapsulated GIST messages (Section 5.3)."
      The DPI mechanism won't work and it should be removed.
      Next in 5.3.2.4 on the discussion of IP options, it is unclear what IP options would want to be set on GIST messages and why. Unless specific IP options are to be used and explained why they are necessary, I believe you should remove the section completely as there is no reference in the rest of the doc (I may be incorrect).
      Last, a disclaimer should be added to the document that this technology is expected to be deployed in specific limited internet domains (e.g. research, enterprise, wall-garden scenarios).

    Telechat:

  2. A One-Way Packet Duplication Metric (Proposed Standard)
    draft-ietf-ippm-duplicate-07
    Token: Lars Eggert
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-02-12]: I wanted to vote Yes on this document, and gave it a detailed read. It is in good shape. However, there was one issue that troubled me. The document says: 
         Two packets are considered identical if and only if:

   o  Both contain identical information fields.  The recipient thus
      could take either packet and use the data in an application.  The
      other packet does not contain any additional information.
   o  Both packets appear to have been sent by one and the same host, to
      one and the same destination.  Host are identified by their IP
      addresses.
   o  Both contain valid, but not necessarily identical IP header
      fields.

      ... and much later ...
      "In IPv4, "information fields" refers to all data following the IPv4 header. The equivalent of this in IPv6 is all information following the IPv6 header and the hop-by-hop options header."
      There are a couple of problems with this. First an editorial comment that as a reader I would have appreciated to have seen the information fields definition earlier (I had scanned all the references before I realized it was defined later in the document).
      Second, I would prefer to see a crisper definition. There aren't too many fields in the IP headers, why not specify exactly what has to be exactly as-is and what can change. My guess is: 
      Must be exactly as-is:
   ipv4: version, ihl, identification, src, dst, protocol
   ipv6: version, next header, source, destination
Can change:
   ipv4: tos, ttl, checksum
   ipv6: traffic class, flow label, hop limit
Not sure what I'd say:
   ipv4: total length, reserved flag bit, DF flag, options
   ipv6: payload length
Not applicable:
   ipv4: fragment offset, MF flag

      Third, what about things like IPv4 Record Route or Timestamp options? Though these might be almost non-existent in real world today, so maybe its fine to treat them as a part of information fields.
      On the IPv6 side, what about routing header type 2? These never change on the wire, but the point at which ippm intercepts the packets matters. RFC 3775 allows them to be processed so that the segments left field is decremented before the rest of the packet is processed. Similarly, there are other packet processing tasks that packets go through when being sent or received, such as IPsec ESP encap/decap. The latter is actually an even more interesting case from the point of view of ippm, because a security gateway might encapsulate the packet and the receiver then decapsulates. Do you consider the ippm as something that processes raw packets, as they are received from the network? If so, you should probably say this explicitly.
    2. Adrian Farrel: Comment [2009-04-03]: Since you will probably need to revise the document for Jari's Discuss, here are some nits to fix along the way.
      Abstract: s/from one host to the other/from one host to another/; s/has been defined/was been defined/
      Section 1.2 - Same changes as Abstract
      Agree with Jari that the definition of "information fields" needs to be moved from 2.5 to above its first use (in section 2.4).
      Section 2.4 bullet 2: s/Host are/Hosts are/
      Section 2.5: s/Clocks do have to be/Clocks have to be/
      Sections 4.1.2 and 4.2.2: Would it help to note Tf > Ts ?
      Did you reach any conclusions with IANA for section 7? If you are respinning the document, it would be good to capture these changes at the same time.

    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. Streaming Internet Messaging Attachments (Informational)
    draft-ietf-lemonade-streaming-10
    Token: Alexey Melnikov Note: Glenn Parsons is document shepherd
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-04-09]: I am concerned about the following. I did not have a lot of time to read the document, so I'm probably missing something, but:
      "If the media server is configured as an authorized user of the IMAP server, it SHOULD authenticate to the IMAP server using the credentials for that user."
      this seems to be saying that the media server needs to hold credentials for the user. The IETF has a rule, I think, against recommending private key sharing or even group shared secrets. Isn't this breaking against that policy?
      Then again, maybe I'm missing something because the rest of the document talks about pawn tickets, which does not seem to match with the above text.
    2. Lisa Dusseault: Comment [2009-03-30]: In the Security Considerations section, last bullet item on p 24, the first media server is inconsistently referred to as either MS1 or M1.
    3. Lars Eggert: Discuss [2009-04-06]: Section 3.7., paragraph 11:
      "The following gives an example dialog between a client and media server, including a rewind request, and termination of the playback by use of the escape key."
      DISCUSS: The XML in the example is invalid (<audio> is never closed). Please check the other examples as well. (Let me know if you want the xmllint output.)
    4. Pasi Eronen: Discuss [2009-04-08]: I have reviewed draft-ietf-lemonade-streaming-10, and have one concern that I'd like to discuss before recommending approval of the document.
      The draft seems a bit thin on how the communication between the client and the media server is secured. Presumably, the client would like to ensure that the media server is trustworthy (and not any random attacker); and the media server may want to provide services only to authorized clients.
      Currently, the draft does mention S/MIME a couple of times, but that does not sound like a realistic security mechanism for environments envisioned in lemonade. Neither is assuming client certificates.
      Could you elaborate a bit on how you're planning to (1) authenticate the client to the media server, and (2) authenticate the media server to the client?
    5. Cullen Jennings: Discuss [2009-04-06]: The security of this draft is predicated on S/MIME and SIPS. Neither of which have ever been deployed and I am told that OMA has no intention of using them. I don't know if the security ADs would be OK with the draft saying no security but if nothing else the document needs to clearly outline the attacks and risks when neither sips or S/MIME is used.
    6. Robert Sparks: Discuss [2009-04-06]: 1: The "=" signs in the play parameter values of the SIP URIs have to be escaped. Please double check the other symbols in the examples and consider pointing to the URI construction section in 3261.
      2: In section 8, aren't the <>'s supposed to be literal? ("<" absolute-URI ">")
    7. Magnus Westerlund: Discuss [2009-04-09]:
      1. A Discuss for discussion in IESG:
      Why is this going for informational status? It seems to me very much be a protocol specification and has lot of normative stuff.
      2. I think there is a big whole in error handling, or at least insufficiently explained. The media server is capable of retrieving the attachment then is completely unable to convert the content of the file into RTP. This can be fore several reasons:
      1. No RTP payload format for the content type
      2. No transcoding from that media format to another that is supported.
      3. The content type is supported however converting this particular file to RTP is not supported due to the complexity in making the content type robust enough for RTP transport.
      I think indicating an error that there is no common format between the media server and the client seems wrong, as the issue is that the media server can't provide any media from the attachment. Can you please elaborate on how this should be handled.
      Comment [2009-04-09]: Section 8:
      Reference to ABNF needs to be udpated.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. IPv6 Rapid Deployment on IPv4 infrastructures (6rd) (Informational)
    draft-despres-6rd-03.html
    Token: Jari Arkko
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-04-02]: Always a shame to see I-Ds for which idnits has not been run. 
        == Unused Reference: 'RFC4291' is defined on line 339, but no explicit
     reference was found in the text
     '[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing Archi...'

  == Unused Reference: 'RFC1918' is defined on line 350, but no explicit
     reference was found in the text
     '[RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., an...'

      The first really does need to be used. The second can be solved by inserting the reerence in section 4.1.
      Section 5
      "CPE PACKETS TOWARD THE INTERNET: The IPv6 source must be, and the IPv6 destination must no be, a 6rd address of the site."
      s/must no be/must not be/

    Telechat:

3.3.2 Returning Items

  1. (none)

1248 EDT break

1253 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Multiple Interfaces (mif)
    Token: Jari

    Telechat:

  2. Network-Based Mobility Extensions (netext)
    Token: Jari

    Telechat:

4.1.2 Proposed for Approval

  1. Locator/ID Separation Protocol (lisp)
    Token: Jari

    Telechat:

  2. Session Initiation Protocol Core (sipcore)
    Token: Cullen

    Telechat:

  3. Dispatch (dispatch)
    Token: Cullen

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. (actually happened at start of meeting)
  2. Dave: 5 items; planning tech plenary: net neutrality, aspects of issues (panel, not judge desirability), contact Marcello; uncoordiated protocols harmful, consensus call soon; TMPLS problems; very close on boilerplate; infrastructure enum (management of DNS, etc.)

6. Management Issues

  1. Approve IANA expert for CAPWAP (Russ Housley)

    Telechat:

  2. Assignment of media type action point to Alexey (Magnus Westerlund)

    Telechat:

  3. ISOC BoT Appointment Confirmation (Executive Session) (Russ Housley)

    Telechat:

  4. LS response to ITU-T SG11 (Lars Eggert)

    Telechat:

  5. eMail access to tools.ietf.org (Russ Housley)

    Telechat:

  6. Last Call issue raised for draft-iana-rfc3330bis (Russ Housley)

    Telechat:

7. Agenda Working Group News

1154 EDT entered executive session