IESG Narrative Minutes

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

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

Corrections from: Cullen, Dan, Pasi

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. SIP Interface to VoiceXML Media Services (Proposed Standard)
    draft-ietf-mediactrl-vxml-04
    Token: Jon Peterson
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2009-02-25]: The use of HTTP POST is incompletely specified. The section 4.1 where this is first mentioned does not even seem normative.
    2. Chris Newman: Comment [2009-02-24]: Section 2.1, page 12, 3rd paragraph after ABNF:
      "Since some applications may choose to transfer confidential information, the VoiceXML Media Server MUST support the sip: scheme as discussed in Section 9."
      I believe this should say "sips:" instead of "sip:" to be consistent with Section 9.
    3. Dan Romascanu: Comment [2009-02-26]: The following issue was raised in the OPS-DIR review by Tina Tsou.
      In section 9 Security Considerations, it says SRTP should be supported to provide confidentiality, authentication, and replay protection for RTP media streams (including RTCP control traffic). However, in above use cases, all the message types are RTP/SRTP. In RTP case, how to guarantee security? So I suggest change “RTP/SRTP” to “RTP and SRTP” in all the use cases or to any other expressions to well express the problem.

    Telechat:

  2. RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec (Proposed Standard)
    draft-ietf-avt-rtp-uemclip-04
    Token: Cullen Jennings Note: The document shepherd is Roni Even
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-05-21]: The legend URL is currently non-existent. It should be created when the document is approved.
    2. Cullen Jennings: Discuss [2009-02-20]: This is not a discuss on the document. There seems to be a problem with the data tracker tool and I am holding a discuss to make sure that positions get correctly entered for this document.
    3. Tim Polk: Comment [2009-02-25]:
      The final clause of the first sentence doesn't quite parse: "This implies that confidentiality of the media streams is achieved by encryption by other means."
      Perhaps the following would be clearer? "This implies that confidentiality of the media streams is achieved by encryption unless the applicable profile specifies other means."
      Magnus Nystrom's secdir review included the following suggestion for the security considerations section:
      The security consideration section notes the risk of memory attacks due to illegal layer indices etc. Maybe it could also be pointed out that decoders could be configured to reject layer indices etc. that are outside of some specified policy?
    4. Magnus Westerlund: Discuss [2009-02-24]: This is a discuss against the RFC-editor note: I don't think the following text belongs to this document:
      Please add the followinf title page header lines:
      Obsoletes: 3978, 4748
      Updates: 2026
      • Section 3. "It should be noted that the location of the core layer may not be located at the top"
        What is the top, do you mean first in the payload, or first in the frame? Please clarify
      • Section 3.1: "For UEMCLIP streams, the RTP timestamp MUST advance based on a clock which is multiple of 8000 (Hz)."
        I think this is in conflict with the Media type that says that the only valid rates are 8k and 16k.
      • Section 3.1: "In cases where the audio sampling rate can change during a session, the RTP timestamp rate MUST equal to the maximum rate (in Hz) given in the mode range (see Section 6.2.1). This implies that the RTP timestamp rate MUST NOT change during a session. For example, during a session with 8-kHz audio sampling, where a transition to a 16-kHz audio sampling mode is allowed, the RTP time stamp must always advance using 16-kHz clock rate."
        In the above requirement I don't think it is at all appropriate for this limitation to apply to the RTP session, only each specific RTP payload type that is using this RTP payload format. Please reformulate to restrict the scope of the rule and the explanation.
      • Section 3.3.1.1: The section lacks an explanation on what to do if one isn't a RTCP terminating-MCU topology.
      • Section 3.3.1.1. "Power #1 (PW1): 5 bits; Signal power code of the current frame."
        What is the interpretation of the 5 bits? If it is a code, where is that code defined. Please include relevant reference. If not available, please define.
      • Section 3.3.1.2: "Pitch lag #1 (P1): 7 bits; Pitch code of the current frame."
        Please include a reference to the definition of the pitch code.
        Applies also to P2.
      • Section 2, and 3.3.2: The support for multiple channels within a single bit-streams very poorly explained.
      • Section 4: It should be noted that this media transcoding is useful only in RTP devices that terminate RTP and RTCP packets.
      • Section 6.1: "Encoding Considerations: This type is defined for transferring UEMCLIP-encoded data via RTP using the payload format specified in Section 3 "Payload Format" of RFC xxxx (this RFC)."
        This text seems to belong to the "Restriction on usage" heading that is missing. It should also say "only defined" unless a file format fulfilling the requirements in RFC 4855 exit.
      • Section 6.1 and 6.2: "Encoding parameters: Since this is an audio stream, the encoding parameters indicate the number of audio channels, and this SHOULD default to "1", as selected from the ones defined in Table 2. This is OPTIONAL."
        The Channels parameter isn't defined. Despite the indications that more than one channel can be supported. Depending on the answer to the earlier question about channels either texts needs changes.
      • Section 6.2: "Packet time: A frame length of any UEMCLIP is 20 ms, thus the argument of "a=ptime" MUST be a multiple of "20". When not listed in SDP, it should also default to the minimum size: "20"."
        This is an unnecessary hard requirement that actually there are reasons to break. I think a SHOULD is appropriate. The reason to break it is when one in SDP Offer/answer suggest multiple payload types and there is other audio codecs that has other frame lengths then 20 ms. This as ptime is not specified on a per payload type basis.
      • Section 6.3.1: "In this case, the offerer MUST use the default value for any deleted parameters."
        I think this sentence is very unfortunate. In case one uses a parameter in the future to find out support, there might not be any default values. And parameters that are defined in this specification are not unknown/undefined. Suggest deleting the sentence.
      • Section 6.3.1: Can you please clarify the meaning of the "mode" parameter when offered in a sendonly media stream.
      Comment [2009-02-24]:
      • Section 1: "It should be noted that, generally speaking, codecs are negotiated and switched using SDP exchange."
        I think the talk about "switched" in the above sentence is potentially missleading. In an negotiated RTP session whit more than one established RTP payload format, there is no need for any SDP signalling to switch between the different RTP payload types. Thus, switched is only correct in the case one are talking about the high level action of deploying a new codec and having it replace another. Please rephrase.
      • Section 3.3.1.2 "Frame indicator"is equal to the difference in the RTP sequence number when one"UEMCLIP frame is contained in a single RTP packet."
        It might be better to express this as the reference is to the UEMCLip frame that has the RTP timestamp value = This frames RTP TS - K*Timestamp_rate/50. This avoids the issues with packet losses or variable number of frames in the payloads.
      • Section 6.1: Rate definition: If the intention is to allow for 32k in the future, I think the best is to be clear that this format doesn't define this and indicate how an implementation of this specification should handle such a case. Explanation probably needs to be split to both this section and SDP mapping part.
      • Section 6.2: "The mode specification"parameters should be defined here (see Section 6.2.1)."
        This sentence seems strange. First of all there are only one "mode" parameter and it is defined in this RFC. I understand that you mean: The "mode" parameter should be included and specify the desired modes for the session.

    Telechat:

  3. IPsec Channels: Connection Latching (Proposed Standard)
    draft-ietf-btns-connection-latching-08
    Token: Name
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-02-25]: This is good stuff, but I had a number of issues relating to imprecise language to describe what exactly is required. Note that as I'm doing this review it is 2AM so it could be just that I'm too tired to understand.
      • "The REQUIRED set of parameters bound in IPsec channels is:..."
        Do you allow both normal IDs and the public key ID introduced in the BTNS core spec (which is an RFC by now, by the way)? See also below?
      • "The SAs that protect a given IPsec channel's packets may change over time in that they may expire and be replaced with equivalent SAs, or may be re-keyed. The set SAs that protect an IPsec channel's packets need not be related by anything other than the fact that they must be congruent to the channel (i.e, the SAs' parameters must match those that are latched into the channel)."
        RFC 4301 talks about partial and exact matches -- presumably you mean the latter above.
        Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1 and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4 but with *different* peer cert CE2 and possibly a different CA CA2? I.e., do you bind to the *name* or the key behind it in those non-BTNS cases?
      • "Implementations that provide such programming interfaces SHOULD make available to applications any available NAT-related information about the peer: whether it is behind a NAT and, if it is, the inner and outer tunnel addresses of the peer."
        I'm curious why this end's NAT data would also not be relevant for this. Or maybe it is not, but after thinking about this for a couple of minutes I can't decide which way it should be. Has the WG considered providing information about the implementation's own perceived status behind a NAT...
        What is "inner and outer tunnel address"? Since you are mentioning this in the context of NATs, do you really mean IPsec tunnel mode inner and outer addresses, or the peer's address inside and outside the NAT?
        Finally, even if NATs are not involved, wouldn't tunnel mode outer addresses be interesting anyway?
      • "Implementations SHOULD create IPsec channels automatically bydefault when the application does not explicitly request an IPsec channel."
        Really? Without no policy whatsoever... I think there should be a knob to enable BTNS, as there would likely be uses of a BTNS capable device where the small additional IKE negotiation delay for a large number of connections would be unacceptable.
      • "CLOSED (by the ULP, the application or administratively) and always have an associated owner, or holder, such as a ULP transmission control block (TCB)."
        Comment: As you mention below this state doesn't really exist any measurable time if the ULP closed it. And it couldn't either, because there would be no TCB to associate with. I wonder if the name of this state would be better as "CLOSING".
      • "informed except where the ownser caused the transition, in which case"
        Typo
      • "CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection parameters]) -> latch handle If there is no conflicting connection latch object in the LISTENER state for the given 3-tuple (local address, protocol and local port number), and local policy permits it..."
        It is interesting that here you have "local policy permits" clause, but for CREATE_CONNECTION_LATCH you do not have one. Is this deliberate, or a mistake?
      • "If no connection latch exists in the ESTABLISHED states with the same 5-tuple, and if there exist no child SAs that match the given 5-tuple, then the system MUST initiate an IKE exchange to setup child SAs for this 5-tuple."
        .. a bit later ...
        "If there exist no child SAs matching the given 5-tuple then the key manager SHOULD try to create a pair of child SAs for that 5-tuple."
        Why the duplication? Or is there some subtle difference that I am not seeing?
      • "CREATE_CONNECTION_LATCH"
        This description does not tell me what happens in the different error cases, e.g., when the if clauses are not fulfilled. For instance, what if there is an existing latch for this 5-tuple and it would even match the required properties?
        When the key manager informs a ULP that a connection latch has been administratively transitioned to the CLOSED state then connection-oriented ULPs MUST act as though the connection has been reset by the peer. Implementations of ULPs which are not connection-oriented, and which have no API by which to simulate a reset, MUST drop all inbound packets for that connection and MUST NOT send any further packets -- the application is expected to detect timeouts and act accordingly.
        How does a "non-connection oriented ULP" "drop all inbound packets for that connection"?
        SA that protected it could expired before..."
        expire? could be expired?
      • "When a connection latch is broken a BITS/BITW/SG implementation may have to fake a connection reset by sending appropriate packets (e.g., TCP RST packets), for the affected connections."
        Is there a corresponding message that could be used with UDP? If not, please state early on that the BITS implementations can only support TCP.
    2. Lars Eggert: Discuss [2009-02-23]: [I-D.ietf-btns-prob-and-applic] has been published as Informational (RFC5387) and this is hence a DOWNREF. I believe it can simply move to the Informative References section, if the first reference to it in the introduction is changed to refer to [I-D.ietf-btns-core] instead (which has since been published as PS as RFC5386).
      Comment [2009-02-23]: I'd be better if Figure 4 and its explanatory text in Section 2.2.2 used the IP ranges set aside for documentation and dynamic port numbers (> 49152).
    3. Russ Housley: Discuss [2009-02-25]" The Gen-ART Review by Elwyn Davies on 24-Feb-2009 includes some very significant comments. Please respond to this review. The review can be found at: http://www.softarmor.com/rai/temp-gen-art/draft-ietf-btns-connection-latching-08-davies.txt
    4. Cullen Jennings: Discuss [2009-02-26]: Imagine the case where a an ULP has sent 30 k of data and stuffed it into a TCP connection but the kernel is still buffering that data and it has not been sent yet. At this point the flow transitions to the BROKEN state. Does the 30k of data sill get sent or not? I could not seem to find the answer to this.
      I would not be surprised if the answer is there and I just missed it so hopefully this can discuss can be resolved with no change to the document.
      Comment [2009-02-26]: I like the concept but wIthout the API's is nothing to standardize here - there no change on the wire, there's no change to anything else. How would a vendor even says they are or are not complaint with this? How would one move it to Draft etc. I think this should normatively depend on the API draft - it means nothing without it.
    5. Chris Newman: Comment [2009-02-25]: I support advancement of this technology, but believe it needs some revision to address comments from Elwyn Davies and IESG discuss positions.
      While I wouldn't necessarily hold up this work waiting for draft-ietf-btns-abstract-api, I will observe that the longer the gap between publication of this draft and the abstract API (or at least a subset of the abstract API necessary for an application to query channel binding and encryption strength), the less likely we'll get deployment of this technology by applications. Application developers have already invested time integrating with TLS stacks to get channel security. They will not spend time integrating with IPsec unless the extensions to the sockets API are the same across platforms that offer socket (Linux, Solaris, MacOS, WINSOCK). Even then, this will be a tough sell.
      Without the application API, this technology provides no useful services to _applications_ as the application can not know whether the channel is protected and thus can not indicate such to the end-user. Only a tiny group of power-users would be capable of configuring their IPsec stack to require IPsec to particular hosts/subnets and understand the security implications of doing so for applications. That's simply not a useful application service.
      It may be wise to design enough of the abstract API (and perhaps non-normatively suggest a sockets/WINSOCK style API extension) to make this useful to applications before publishing this. After all, the draft includes a "SHOULD" that can't be done in an interoperable fashion without such work.
    6. David Ward: Discuss [2009-02-24]: A few unrelated comments:
      - Once one can latch flows to an IPsec tunnel then one may want to latch flows to a backup tunnel so that in the event of a failure there is orderly migration of traffic
      - A reader/implementor has to derive the action to take if a tunnel goes down and there are other possible routing paths to the destination and what is supposed to happen. I suggest that there is a brief section on failure cases
      - How can this technology be used for IPsec VPNs? Can a router latch flows between two VPNs or AFBRs? How?

    Telechat:

  4. RTP Payload Format for the Speex Codec (Proposed Standard)
    draft-ietf-avt-rtp-speex-05
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-02-23]:
      "9. Copying conditions; The authors agree to grant third parties the irrevocable right to copy, use and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information."
      Discuss-discuss: I'd like to ask for clarification on how this statement intersects with the Trust boilerplate during the telechat. I expect to ballot no-objection after the discussion.
    2. Chris Newman: Discuss [2009-02-25]:
      Although the MIME specification does not appear to forbid the same content type parameter from appearing twice (something that's unlikely to work in practice), it is explicit that order of parameters is not significant (meaning a processor is free to re-order them).
      RFC 2045, p 10 at the bottom: "The ordering of parameters is not significant."
      That means it is not acceptable for a media type registration to impose an ordering restriction on content-type parameters as this one does.
      So if you want order to matter, you need to encode the mode values as a comma-separated or space-separated list.
    3. Magnus Westerlund: Discuss [2009-02-25]: I am missing an explicit mentioning that the Speex payload format only support single channel (mono) audio. That is important as otherwise the channel parameter is required.
      • Section 3.3:
        There is no explicit mentioning that the Speex frames must be placed starting with the oldest and then continue consecutive in time. I know it is implied by the sentence about taking the encoder input in the order it is produced. However, can you please add this? There are two reasons. First of all the timestamp definition says that the timestamp is for the first frame. Which means unless it is clear that the first frame is the oldest it is not clear that the timestamp is for the oldest one. Secondly, without a constraint on consecutive ones then frame loss at translators repacking frames could allow for putting non-consecutive frame hiding the loss and moving the timeline.
      • Section 4.1.1: "cgn" parameter, is missing a default value.
      • section 4.1.1: "mode" parameter:
        The syntax of the parameter value is not clear. Please be explicit about the syntax of the value field. If only single tokens or a quoted list of comma separated values is allowed also?
        Secondly the preference scheme is not clear. As encoding and decoding capabilities are different it is not clear which is encoding preferences and which is decoding capabilities. For example mode=3;mode=8;mode=any could be perhaps be interpreted as prefer encoding in mode 3 and then 8 but can receive any. But mode=3,5,1,2,3,4,5,6 is not clear what it means. Which are encoding and which are decoding.
      • section 5: "The Speex parameters in an SDP Offer/Answer exchange are completely orthogonal, and there is no relationship between the SDP Offer and the Answer."
        The above sentence does not make sense. Due to that the mode parameters seems to declare encoding and possibly also decoding capabilities there will be a relation ship between the offer and the answer. What one side encodes needs to be decoded on the otherside. So if there are any capabilities expressed with mode, then this clearly needs to be expressed.
        Also with preference parameters there becomes issues in declarative usage. Especially for multipart conferencing where all participants are using the same. Some discussion on the need avoid to limitation also seems appropriate. But first we need to sort out what mode really does.
      • Section 5.6: "Values of ptime which are not multiples of 20 MUST be rounded up to the first multiple of 20 above the ptime value."
        It is not clear that this is the interpretation of values other than 20ms that you receive in an SDP, rather than a requirement for what you may encode in the parameter ptime.

    Telechat:

  5. Quality of Service Parameters for Usage with Diameter (Proposed Standard)
    draft-ietf-dime-qos-parameters-09
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2009-02-26]:
      The text about QoS Profile IDs (in last paragraph of Section 4 and Section 5.2) doesn't make sense as is. The intent probably is that the first four octets are an IANA-assigned Enterprise Number, and for the latter four octets, IANA maintains a registry for Enterprise Number 0 (but for other Enterprise Numbers, it's up to the owner how they're used).
      But that's not quite what the text currently says (in 4.2, the sentence "If the four octets.." does not parse, and in 5.2, it suddenty starts talking about OIDs ).
      Also, what's the IANA assignment policy for numbers 4096..4294967295?
    2. Chris Newman: Discuss [2009-02-25]: This document has the following flaws:
      1. It names the "Diameter" protocol without providing a reference to the protocol specification.
      2. This uses a formal grammar to define protocol elements without providing a reference to the definition of the formal grammar.
      I believe both problems are resolved by adding the missing normative reference to the Diameter base specification.

    Telechat:

  6. RTP Payload Format for ITU-T Recommendation G.722.1 (Proposed Standard)
    draft-ietf-avt-rfc3047-bis-08
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Tim Polk: Discuss [2009-02-25]: This is primarily a process discuss, but I believe the change proposed below would significantly improve the document. Alexey Melnikov's secdir review has not received a response. He suggested expanding the first paragraph in the security considerations to provide more background to a reader unfamiliar with RTP on the range of possible security mechanisms.
      He has proposed text (from RFC 5404); I would like to know if the authors feel this suggestion is innapropriate.
    2. Dan Romascanu: Discuss [2009-02-26]: "The new draft obsoletes RFC3047 adding the support for the Superwideband (14 Khz) audio support defined in annex C of the new revision of ITU-T G.722.1."
      There is no indication about the backwards compatibility of this specification (I think that the word 'draft' must be replaced in the final version of the document) and RFC 3047. Will th epaylod format described here be accepted and correctly processed by RFC 3047 compatibe devices, excepting for Superwideband support? Are there any oth er operational implications of deploying devices that support the new format?

    Telechat:

  7. Signaling media decoding dependency in Session Description Protocol (SDP) (Proposed Standard)
    draft-ietf-mmusic-decoding-dependency-06
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Magnus Westerlund: Discuss [2009-02-26]:
      • Section 5.2.2: "The depend-attribute describes the decoding dependency. The depend-attribute MUST be followed by a sequence of dependent-fmt and the corresponding dependency-tag fields which identify all related media format descriptions in all related media descriptions of the dependent-fmt."
        The ABNF allows one to include no related media format descriptions. Can you please clarify the meaning of that. It seems that the dependency type overrules that possibility in some cases. Maybe that should be made explicit.
      • Section 6.1: I am missing a clarification what the meaning of a=depend is in the cases with offers with send-only, sendrecv and recvonly. It is not clear from section 5.2.2 that a=depend applies to received media or sent media. Based on that how too layer things usually are a sender configuration, this clashes with offer/answer. Please clarify this relation ship.
        I think a specific offer/answer example will also be warranted as soon as the mechanism has been worked out.
      • Section 8: The following semantics have been registered by IANA in Semantics for the "depend" SDP Attribute under SDP Parameters: 
           Semantics of the "depend" SDP attribute:

   Semantics                                Token     Reference
   ----------------------------             -----     ---------
   Layered decoding dependency              lay       RFC XXXX
   Multi descriptive decoding dependency    mdc       RFC XXXX

        This registry lacks definition! Please provide registration rules for it.

    Telechat:

  8. Source-Specific Media Attributes in the Session Description Protocol (SDP) (Proposed Standard)
    draft-ietf-mmusic-sdp-source-attributes-02
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-02-25]: "According to the defintion of SDP, interpreters of SDP session"
      Typo
    2. Russ Housley: Comment [2009-02-25]: Please consider these editorial comments raised by Francis Dupont in the Gen-ART Review on 5-Feb-2009.
      - Abstract page 1: The Session Description Protocol -> ... (SDP)
      - 3 page 4: receivers (who may never -> receivers (which may never
      - 3 page 4 (twice): i.e. -> i.e.,
      - 4 page 5: synchronizaton -> synchronization
      - 9 page 12: defintion -> definition
      - 10 page 12: 0 - 2**32 - 1 -> 0 .. 2**32 - 1
      - 12.3 page 15: gropuing -> grouping
      - Authors' page 18: NJ 07601, US -> NJ 07601, USA
    3. Magnus Westerlund: Discuss [2009-02-25]:
      Section 10: "ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)"
      The text points at RFC 3388 for the definition of "semantics". However RFC 3388 definition is:
      semantics = "LS" | "FID"
      Based on the IANA rules it is clear that this rule should in fact be:
      semantics = "LS" | "FID" | token
      token as defined by RFC 4566. Based on this is seems approriate that this is converted into consistent ABNF and put into this document. It can also be limited to the semantics actually defined. Resulting in:
      semantics = "FEC" / "FID" / token
      token = <see RFC 4566 definition>

    Telechat:

  9. Support for Reduced-Size RTCP, Opportunities and Consequences (Proposed Standard)
    draft-ietf-avt-rtcp-non-compound-09
    Token: Cullen Jennings Note: Tom Taylor is Proto Shepherd
    Extracted from Balloting:
    1. (none)

    Telechat:

  10. Conference Event Package Data Format Extension for Centralized Conferencing (XCON) (Proposed Standard)
    draft-ietf-xcon-event-package-01
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-02-26]: Please consider these comments from the Gen-ART Review by Pete McCann. These are not addressed in the current RFC Editor note.
      Section 5.1 says: "When the server receives a SUBSCRIBE request (refresh or termination) within the associated subscription, it SHOULD send a NOTIFY request containing the full document using the 'application/ xcon-conference-info+xml' content type."
      Do you really want to send the full document upon termination of the subscription?
      Section 3: s/instance has experimented/instance has experienced/
      Section 5.2:
      s/received in notification/received in the notification/
      s/If subscriber/If the subscriber/

    Telechat:

2.1.2 Returning Items

  1. (none)

2.1.3 For Action

  1. RPC: Remote Procedure Call Protocol Specification Version 2 (Draft Standard)
    draft-ietf-nfsv4-rfc1831bis-12
    Token: Lars Eggert Note: Document Shepherd: Spencer Shepler (spencer.shepler@gmail.com)
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-12-11]: Christian Vogt's review: ... Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.
      Document draft-ietf-nfsv4-rfc1831bis-10 is an update of the "Remote Procedure Call Protocol Specification Version 2", RFC 1831. It seeks to promote the RPC protocol to draft standard. The document is overall in good quality.
      However, one aspect where I found the document to be insufficient is in the specification of security methods. The documents does list possible security methods, but it neither specifies them, nor does it state a mandatory-to-support method other than null-authentication...
      Suggestion: Could the list of possible security methods (alias "security flavors") be limited to those for which there are clear protocol specifications? E.g., one of the possible methods, AUTH_DH, currently refers to an academic publication rather than a protocol specification. That's insufficient. And could one of the non-null security methods be made mandatory?
    2. Lisa Dusseault: Comment [2008-12-10]: I support the various DISCUSS positions
    3. Pasi Eronen: Comment [2009-02-02]: Editorial nit: Section 8.3, the chart isn't actually "in groups of hexadecimal 20000000" any more (it was in 1831).

    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. Reliable Server Pooling MIB Module Definition (Experimental)
    draft-ietf-rserpool-mib-11
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Ron Bonica: Comment [2009-02-25]: Support Dan's discuss
    2. Pasi Eronen: Comment [2009-02-26]: I support Dan's discuss about the security considerations text.
    3. Russ Housley: Discuss [2009-02-20]: Bert Wijnen pointed out that the MIB document does not follow the MIB guidelines. Bert found two things that ought to be corrected:
      - read-write objects where the document do not state the expected persistency behaviour
      - missing copyright statement in the MODULE-IDENTITY descritpion clause
    4. Cullen Jennings: Comment [2009-02-25]: Support Dan's discuss.
    5. Dan Romascanu: Discuss [2009-02-23]: This document was discussed on the MIB Doctors and OPS-DIR lists. The content of the DISCUSS and COMMENT was contributed by David Harrington, bert Wijnen and Tina Tsou.
      1. The Security Considerations section does not follow the guidelines in http://www.ops.ietf.org/mib-security.html . As a result only SNMPv1 is mentioned (as NOT RECOMMENDED) rather than 'SNMP versions prior to SNMPv3' and the vulnerability of the read-write objects is not described.
      2. There are a number of read-write objects in the MIB module, but there is no definition of the persistency behavior of these objects in case of reset or reinitialization.
      3. There is no copyright statement in the MODULE-IDENTITY description clause
      4. Tha IANA considerations section must specify that the allocation is to bemade from the Experimental tree.
      5. I do not believe that the definition of the RserPoolDescriptionTC is justified. All over the MIB module this TC is used just for Description objects, no semantics. Using OCTET STRING for SYNTAX of these seems better, also I recommend to restrict the SIZE to something smaller than 4095

      Comment [2009-02-23]:
      1. ENRP is never expanded in the text.
      2. I do not believe that copying all objects in the tree in Section 4 is useful.
      3. It would be very useful to add REFERENCE clauses to the MIB objects which would help understanding the functionality by refering to the precize clauses in other rserpool documents.
      4. The DESCRIPTION clauses of the TCs are extremely succint and do not help understand the funmctionality.
      5. Why are some TCs limited to 65536 while other run to 4294967295
      6. There is no discussion in the document of why this is an experimental track MIB module, and what that means to implementers and deployers. This should be documented in an Operational Consideration section, or something similar, if not the abstract and Introduction.
      7. The MIB defines an rserpoolENRPIndex ""An integer to uniquely identify an ENRP server." and a rserpoolENRPIdentifier column in the row "The ENRP server identifier of this ENRP server." Is there a one-to-one correspondence? or can there be multiple rows with the same rserpoolENRPIdentifier?

    Telechat:

  2. An Architectural Framework for Media Server Control (Informational)
    draft-ietf-mediactrl-architecture-04
    Token: Jon Peterson
    Extracted from Balloting:
    1. Cullen Jennings: Discuss [2009-02-25]: This is trivial to resolve regardless of if the answer is yes or no. Does this draft need the pre4378 text legend?

    Telechat:

  3. Pre-Congestion Notification (PCN) Architecture (Informational)
    draft-ietf-pcn-architecture-09
    Token: Lars Eggert Note: Scott Bradner (sob@harvard.edu) is the Document Shepherd
    Extracted from Balloting:
    1. Russ Housley: Comment [2009-02-23]: The Gen-ART Review by Francis Dupont on 2009-02-23 provides many minor suggestions. Please review them.
    2. Cullen Jennings: Discuss [2009-02-25]: This is trivial to resolve regardless of if the answer is yes or no. Does this draft need the pre4378 text legend?
    3. Dan Romascanu: Discuss [2009-02-26]: Although never expanded in the document, the acronym OAM is widely used in Section 9 as short for Operations and Management.
      There is an ongoing inconsistency in the industry and the IETF about what OAM is supposed to mean. An I-D draft-andersson-mpls-tp-oam-def tries to put some order, and OAM is meant to be expanded differently then in this document. It would be very useful if this document would not deepen the inconsistency. For this purpose I suggest that all occurences of 'OAM' be replaced by 'Operations and Management' all over this document.
    4. David Ward: Discuss [2009-02-24]: This idea appears to have the issue that if the variance introduced by new sessions coming on exceeds the tolerance in the marking zone (eg, if there is plenty of capacity for one HDTV stream but not enough for two, and someone turns on a second TV while the first is watching a show), that can impact the application in the existing channel. The simulations have tested the ability of the system to operate when properly operated and properly configured; they have not seriously considered avalanche scenarios.
      Avalanche scenarios are a variation of the "mother's day" problem, on a millisecond time scale; in real time applications such as voice and especially video it is possible to outrun an essentially infinite bandwidth pool during short time scales. Consider concerns with realtime video conferencing and the very careful planning to ensure that the network can handle that class of traffic - on a 45 MBPS link with three data streams that nominally run 5 MBPS standing and ~12 MBPS at peaks (I-frame). There are demonstrated issues in picture quality due to conniption fits in the network and as a result force more careful traffic pacing.
      I think this is fine in parts of the network where avalanche scenarios are unusual but, that has to be clearly stated and that the idea does not work in other use cases.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1233 EDT break

1240 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Network File System Version 4 (nfsv4)
    Token: Lars

    Telechat:

  2. Ad-Hoc Network Autoconfiguration (autoconf)
    Token: Jari

    Telechat:

  3. Routing Over Low power and Lossy networks (roll)
    Token: David

    Telechat:

4.2.2 Proposed for Approval

  1. IP Performance Metrics (ippm)
    Token: Lars

    Telechat:

5. IAB News We can use

  1. Loa: discussing NAT66, hoping to publish by Monday; in process of appointing new IESG liaison; approved IESG slate yesterday, hoping to announce soon (after contacting individuals involved)

6. Management Issues

  1. UPDATED: Document Submission cutoff for IETF 74 (Russ Housley)

    Telechat:

  2. Second Nomcom appointment to the IAOC (Ross Callon)

    Telechat:

  3. Confirm way to include license text in I-Ds (Cullen Jennings)

    Telechat:

  4. Rsync variance draft for pre-review version 0 (Dave Ward and Russ Housley)

    Telechat:

  5. Deleted IPR Statements (Russ Housley)

    Telechat:

  6. IDNA recharter (Lisa)

    Telechat:

  7. Bug in Tracker (Dan)

    Telechat:

7. Agenda Working Group News

1401 EDT Adjourned