IESG Narrative Minutes

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

Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)

Corrections from:

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 Submissions

2.1.1 New Items

  1. The Minimum Rank with Hysteresis Objective Function (Proposed Standard)
    draft-ietf-roll-minrank-hysteresis-of-10
    Token: Adrian Farrel
    Note: JP Vasseur (jpv@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-roll-minrank-hysteresis-of):
    1. Ralph Droms: Discuss [2012-05-10]:
      These Discuss points are all intended to ask about design decisions and suggest clarifications. No action is required by the authors until these points have been discussed.
      1. Why is one objective function defined for several potential metrics? The details of MRHOF seem to preclude the establishment of several RPL instances in an LLN, each of which uses MRHOF with a different selected metric.
      2. How are the nodes in the RPL instance informed about the selected metric? My understanding of RPL is that only the objective function is included in the DIO received as an advertisement for a particular RPL instance, which means a node can't know the selected metric for that RPL instance and can't meaningfully decide among multiple RPL instances all using MRHOF as the objective function.
      As a followup to (1), if there were a way to encode the selected metric for a RPL instance in the DAO, a node would be able to select which RPL instance to use for a particular type of traffic.
      3. Based on (1) and (2), would configuration and selection issues be ameliorated if the five candidate selected metrics were each assigned a separate objective function? Use of a separate OF code point for each of the five possible selected metrics would allow multiple RPL instances.
      4. Related to the above, I don't see anything in section 6 about managing the selected metric. Don't all of the nodes that join a RPL instance using MRHOF have to be configured to use the same selected metric?
      5. In section 3.2.2: "a node MAY use a different objective function to select which of these neighbors should be considered to have the lowest cost."
      seems to contradict the statement in the Introduction that "all nodes in a network use a common OF." Should "different objective function" be replaced with "some other selection criteria?"
    2. Ralph Droms: Comment [2012-05-10]:
      These Comment points are non-blocking editorial suggestions.
      1. In the Introduction, s/OF/objective function/ ; the abbreviation OF doesn't appear to be used anywhere else in the document.
      2. Is the second paragraph in section 3.1 equivalent to writing: "If a non-root node does not have metrics to compute the path cost through any of the candidate neighbors, [...]"
    3. Wesley Eddy: Comment [2012-05-09]:
      I support point 2 of Brian's DISCUSS.
    4. Stephen Farrell: Comment [2012-05-09]:
      - Hysteresis could do with a definition - many non-native English speakers (and native speakers!) might have to go look it up so why not save them the trouble?
      - ETX is used without expansion of reference in the intro. Link color is used in 3.3 but not defined. It'd be good to be clearer that those are defined in 6551.
      - This smells experimental to me. I wondered if it had already been implemented/tested. (Not a requirement for PS, so I'm just asking.)
      - You RECOMMEND use of security mechanisms if there is a risk. Can't you be more specific on which security mechanism you mean (e.g. referring to the right bit of 6550, maybe 10.6)? I've not made this a discuss since I hold one on the security framework and perhaps the inability to pick something concrete here will be resolved as a side-effect of that.
    5. Brian Haberman: Discuss [2012-05-02]:
      I found this draft to be rather straightforward to understand, but have a few points I would like clarified (possibly just for me)...
      1. In sections 3.1 and 3.2.1, the draft says that messages can be delayed but should not be delayed too much? How much is too much? Is it dependent on the metric being used? Are there guidelines that should be provided? If different implementations try to interact, will their selection of delay values hinder performance/stability of the RPL-based network?
      2. Section 5 says, "The best values for these parameters should be experimentally determined." Is this guidance to implementers to figure out what values to support in their implementation or advice to operators to test a range of values for their particular deployment? As a standards-track document, this type of nebulous statement concerns me from a variety of perspectives.
      3. Section 8 asks IANA to allocate a code point, but where in the draft is that code point used? Is it used as a part of the transmission logic in section 3.4?
    6. Brian Haberman: Comment [2012-05-02]:
      I support Barry's comment on the confusing use of SHOULDs+MAYs and would like to see those cleaned up.
      1. The Introduction uses several acronyms without any expansion (OF, DAG, ETX). These should be expanded on first use and possibly augmented with a reference (e.g., ETX).
      2. Section 3.1 uses DODAG with no expansion or reference.
      3. A forward pointer to section 5 in section 3.2.2 would make sense for the constants/variables referenced.
    7. Russ Housley: Comment [2012-05-06]:
      Please consider the editorial issues raise in the Gen-ART Review by Miguel Garcia on 27-Mar-2012.
    8. Barry Leiba: Comment [2012-04-29]:
      Substantive comments; please adopt or respond to these:
      Nice, easy-to-read document. Only one substantive comment, about 2119 language:
      -- Section 3.2.1 --
      The use of SHOULD and MAY here is inconsistent -- the MAY turns the SHOULD into something more optional than a SHOULD ought to be. I suggest not using MAY, and rephrasing this way (unless I misunderstand the meaning here):
      NEW: If, despite the above, it is necessary to defer the parent selection until a later time, note that doing so can delay the use of better paths available in the network.
      ========
      Editorial suggestions. No need to respond to these; take them or modify them as you please:
      -- Section 1 -- "Because MRHOF seeks to minimize path costs as described by metrics, it can only be used with additive metrics. MRHOF ignores metrics that are not additive."
      Is it really "ignores"? Or "does not support"?
      -- Section 2 --
      OLD: Path cost is obtained by summing up the selected metric of the links or nodes along the path.
      NEW: Path cost is obtained by summing up the values of the selected metric for the links or nodes along the path.
    9. Robert Sparks: Comment [2012-05-07]:
      I made the same observations in my review that Barry reports in his comments. Please also consider clarifying that no one node sums up the values of the selected metrics in the definition of path cost - rather, each node adds to the cost reported by the parent (section 3.1) resulting in a total for the path.
    10. Martin Stiemerling: Discuss [2012-05-07]:
      Section 3., paragraph 1: "This computation MAY also be performed periodically. Too much delay in updating the path cost after the metric is updated or a new metric advertisement is received can lead to stale information."
      Is there any recommendation or further reading on what the time is to be used to perform the periodically updates?
      Re-computing state periodically might be a good thing, but I would expect that a Standards Track document is much more specific on this.
      Section 2., paragraph 1: "The parent selection MAY be deferred until a later time. Deferring the parent selection can delay the use of better paths available in the network."
      How much is the 'later time'? I would expect that a Standards Track document is much more specific on this, other than do whatever you think is appropriate.
      Section 5., paragraph 9: "The parameter values are assigned depending on the selected metric. The best values for these parameters should be experimentally determined. The working group has long experience routing with the ETX metric. Based on those experiences, these values are RECOMMENDED:"
      Is there any reference on how the WG came to the below numbers? This would be good for people trying to follow this up in the future. They might need to know how to came to these numbers.
    11. Martin Stiemerling: Comment [2012-05-07]:
      - I support Barry's comment on SHOULD/MAY usage
      - More points here:
      Section 1., paragraph 1: "An objective function specifies how RPL [RFC6550] selects paths. For example, if an RPL instance uses an objective function that minimizes hop-count, RPL will select paths with minimum hop count. RPL requires that all nodes in a network use a common OF; relaxing this requirement may be a subject of future study."
      Expand abbreviation OF on first use.
      Section 1., paragraph 4: "This specification describes MRHOF, an objective function for RPL. MRHOF uses hysteresis while selecting the path with the smallest metric value. The metric that MRHOF uses is determined by the metrics in the DIO Metric Container. For example, the use of MRHOF with the latency metric allows RPL to find stable minimum-latency paths from the nodes to a root in the DAG instance. The use of MRHOF with the ETX metric allows RPL to find the stable minimum-ETX paths from the nodes to a root in the DAG instance. In the absence of a metric in the DIO Metric Container or the lack of a DIO Metric Container, MRHOF defaults to using ETX to compute Rank, as described in Section 3.5."
      Expand abbreviation MRHOF on first use (sort of first in the introduction). Expand DAG and ETX on first use, probably add reference.

    Telechat:

  2. Update to MIME regarding Charset Parameter Handling in Textual Media Types (Proposed Standard)
    draft-ietf-appsawg-mime-default-charset-04
    Token: Barry Leiba
    Discusses/comments (from ballot draft-ietf-appsawg-mime-default-charset):
    1. Adrian Farrel: Comment [2012-05-05]:
      I struggled a bit with the escape clauses for the "SHOULD" statements, but I think I got it straight, and I support the publication of this document.
    2. Stephen Farrell: Comment [2012-05-09]:
      I'm a bit confused here, and would like to check how much:-)
      Old subtypes use ascii as a default but don't say that explicitly and will not be changed by this RFC. New subtypes SHOULD NOT define a default. So when I go look at the registry do I need to compare the date of registration vs. the date of this RFC to know what's what?
    3. Russ Housley: Comment [2012-05-06]:
      Please consider the editorial issues raise in the Gen-ART Review by Vijay Gurbani on 27-Apr-2012.

    Telechat:

2.1.2 Returning Items

  1. (none)

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. Reporting Metrics: Different Points of View (Informational)
    draft-ietf-ippm-reporting-metrics-08
    Token: Wesley Eddy
    Note: Henk Uijterwaal (henk@uijterwaal.nl) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-ippm-reporting-metrics):
    1. Benoit Claise: Comment [2012-05-10]:
      - Please address the OPS-DIR review by Bert Wijnen
      "The one thing that concerns me a little bit is the fact that this document uses RFC2119 language. I think that is in-appropriate. Using lower case for the MUST, SHOULD and RECOMMEND in the document is perfectly fine I think."
      - Support Adrian's comment regarding the title "Reporting IP Network Performance Metrics: Different Points of View"
      - Next to the question "How will the results be used?", it would have been nice to ask the question "Which audience will read the results"
      Network Characterization = network operator Application Performance Estimation = application designer, service developer, etc..
      Actually, this is what you did, without clearly mentioning it, asking the question about "how", and answering with "two main audience categories"
      2. Application Performance Estimation - describes the network conditions in a way that facilitates determining affects on user applications, and ultimately the users themselves. This point-of-view looks outward, toward the user(s), accepting the network as-is.
      What do you mean "accepting the network as-is."? It's not because the results will be used for application performance estimation that you can't optimize your network.
      - "The scope of this memo primarily covers the design and reporting of the loss and delay metrics [RFC2680] [RFC2679]."
      What do you mean by design of metric? Do you mean choosing the measurement characteristics of a metric? Note: multiple occurrences of "metric design" in the draft.
      - Section 2: "These memos effectively describe two different categories of metrics,
      "o [RFC3148] includes restrictions of congestion control and the notion of unique data bits delivered, and
      "o [RFC5136] using a definition of raw capacity without the restrictions of data uniqueness or congestion-awareness.
      "It might seem at first glance that each of these metrics has an obvious audience (Raw = Network Characterization, Restricted = Application Performance), but reality is more complex and consistent with the overall topic of capacity measurement and reporting. For example, TCP is usually used in Restricted capacity measurement methods, while UDP appears in Raw capacity measurement."
      I was not sure what you meant by Raw and Restricted.
      However, I saw a definition way down in the document, in section 6 and 7 Raw capacity refers to the metrics defined in [RFC5136] which do not include restrictions such as data uniqueness or flow-control response to congestion...
      "Restricted capacity refers to the metrics defined in [RFC3148] which include criteria of data uniqueness or flow-control response to congestion..."
      Please add those "definitions" in section 2. It's specifically important since RFC5136 and RFC3148 don't mention Raw/Restricted
      - I learned to avoid "we", "our", "us" in RFCs. I double-checked if it's still the case with the RFC-editor. I will let you know the answer.
      - I would add an extra point to "For these and other reasons, such as" Something such as:
      "o the ability to drill down to a specific measurement interval for deeper analysis"
      Justification: most of the time, when checking SLA, we check with large measurement interval, but want to ability to do a postmortem analysis
      - I don't understand
      "Fortunately, application performance estimation activities are not adversely affected by the estimated worst-case transfer time. Although the designer's tendency might be to set the Loss Threshold at a value equivalent to a particular application's threshold, this specific threshold can be applied when post-processing the measurements. "
      - "We can say that the Delay and Loss metrics are Orthogonal"
      Orthogonal -> orthogonal?
      - section 7.4. Bulk Transfer Capacity Reporting: "When BTC of a link or path is estimated through some measurement technique, the following parameters SHOULD be reported:"
      Also transport type, link layer type, tunneling yes/no, etc...?
      - Personal preference, no need to modify the document unless you feel like it.
      All my customers are interested in delay, loss, and delay variation (jitter). It would have been nice to have a clear pointer in the table of content, with a clear entry "Effect of POV on the Delay Variation Metric . . . . . . . . . . . . . ." instead of addressing delay variation in "delay metric" section 5.1.3
      Section 4.1 of [RFC3393] describes this specification and its rationale (ipdv = inter-packet delay variation in the quote below).
      Use IPDV (Remember you used Packet Delay Variation (PDV)) in the document, and refer to RFC5481
      Several ipdv instances in the draft.
      "Network Characterization has traditionally used Poisson-distributed inter-packet spacing, as this provides an unbiased sample."
      Is this correct? or Poisson-distributed start, with fixed inter-packet spacing, to match, for example, a voice/video application
    2. Adrian Farrel: Comment [2012-05-05]:
      I have no objection to the publication of this document, but I think it would be helpful if the document title reflected the fact that the metrics being reported are IP network performance metrics. Perhaps... "Reporting IP Network Performance Metrics: Different Points of View"
      I also have some small Comments as follows...
      (7 items)
    3. Stephen Farrell: Comment [2012-05-09]:
      - 3.1: what does it mean to say the 51 seconds value was "calculated above" when its (now, presumably) done in 4.1.1. (Couldn't you have arranged that 42 seconds was the answer?)
      - 8.2: might have been a nice thing to include some reasonable representative sample sizes for some statistics for some measurements. Definitely too much to try add something with broad coverage, but one good, and one bad, set of example numbers would be a fine addition if someone had time.
    4. Russ Housley: Comment [2012-05-09]:
      Thank you for considering the minor comments and editorial comments raised by Vijay Gurbani in the Gen-ART Review posted on 8-May-2012.
    5. Barry Leiba: Comment [2012-04-28]:
      Substantive suggestions; please respond to these:
      -- Section 5.2 -- "When both the sample mean and median are available, a comparison will sometimes be informative, because these two statistics are equal only when the delay distribution is perfectly symmetrical."
      I'm not a statistician, but I don't think that's true. For example, this has a symmetrical distribution with 5 as the mean and median:
      1 1 4 4 5 6 6 9 9
      But this also has mean and median of 5, and its distribution is not symmetrical:
      1 2 3 4 5 6 6 9 9
      Am I missing something?
      ========
      Editorial suggestions. No need to respond to these; take them or modify them as you please:
      (11 items)
    6. Pete Resnick: Comment [2012-05-09]:
      As per your reply to Eliot Lear's Apps Directorate review, please un-2119 the document. I don't think it's appropriate for this document.
      You say "packets of type-P". Shouldn't that be "packets of type P" without the hyphen? Also, "type C"? With the hyphens, I'm not quite sure what you're talking about. Perhaps this is just unclear to someone outside the area.

    Telechat:

  2. Application-Layer Traffic Optimization (ALTO) Requirements (Informational)
    draft-ietf-alto-reqs-14
    Token: Wesley Eddy
    Note: Enrico Marocco (enrico.marocco@telecomitalia.it) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-alto-reqs):
    1. Benoit Claise: Discuss [2012-05-09]:
      Looking at Adrian's feedback on this draft, I support his DISCUSS:
      Section 3.1 needs to discuss manageability requirements for the new protocol(s). RFC 5706 may give you some guidance.
      And as OPS A.D., I would like to carefully double-check this. Hence this new DISCUSS position... on the top of the having some COMMENTS (the ones mentioned "Substantive suggestions; please adopt or respond to these:") that could potentially be DISCUSS
    2. Benoit Claise: Comment [2012-05-08]:
      Substantive suggestions; please adopt or respond to these:
      - Section 1. Introduction: "Usually, it would be difficult or even impossible for application entities to acquire this information by other mechanisms, e.g., using measurements between the peers of a P2P overlay, because of complexity or because it is based on network topology information, network operational costs, or network policies, which the respective network provider does not want to disclose in detail."
      "difficult or even impossible", "because it is based on network topology information, network operational costs, or network policies, which the respective network provider does not want to disclose in detail. "
      TWAMP type probes, even at the applications level, are possible, and not difficult. However, I believe that the real issue is the scalability: way too many peers in a P2P. That would imply network operational costs, sure. But you don't always need the network topology information, if you "just" want to test for the nearest peer. It would be great if you could update the text.
      - Section 2.3: This document itemizes requirements for the following components: ALTO client protocols, ALTO server discovery mechanisms, host group descriptors, rating criteria, and host characteristics attributes. Furthermore, requirements regarding the overall architecture, especially with respect to security and privacy issues, are presented."
      I was confused by the plurals of these terms. Are you actually proposing multiple solutions? I found my answer later in the doc.:
      "The detailed specification of an ALTO client protocol is out of the scope of this document. In fact, this document does not even assume that there is only one single protocol specification. However, this document enumerates requirements for ALTO, to be considered when specifying, assessing, or comparing protocols and implementations."
      You should move this paragraph in section 2.3, or at least put a similar explanation in 2.3
      - REQ. ARv14-12
      So basically, this is a generic requirement that ALTO is not suited for any real-time rating criterion. Do I get this right? Should you then write something such as: ALTO client protocol specifications MUST NOT define any rating criteria that vary at an order of magnitude equivalent to the RTT
      - REQ. ARv14-5: An ALTO client protocol MUST be extensible to enable support of other host group descriptor types in future. An ALTO client protocol specification MUST define an appropriate procedure for adding new host group descriptor types, e.g., by establishing an IANA registry.
      Why don't you reuse an existing registry, in which you will have all the Information Elements already defined? I have in mind: the IPFIX I.E. in IANA When you will control your applications with ALTO, you will anyway want to apply a flow measurement to monitor your changes, and to serve as a feedback loop for more optimizations. Therefore, it would make sense to have consistent data models between ALTO and IPFIX.
      Proposal:
      1. New text; REQ. ARv14-5: An ALTO client protocol MUST be extensible to enable support of other host group descriptor types in future. An ALTO client protocol specification MUST define an appropriate procedure for adding new host group descriptor types, e.g., by establishing or reusing an IANA registry.
      2. At the protocol design time, reusing the IPFIX ElementID
      - REQ. ARv14-28: An ALTO client protocol MUST use TCP based transport.
      I don't understand why you impose this? If SCTP is ever deemed to be beneficial... However, if you have a good reason to explicitly mandate TCP, please explain it.
      - REQ. ARv14-48: An ALTO server MUST provide adequate guidance even if the ALTO client prefers not to specify the desired resource (e.g., keeps the data field empty).
      I don't understand this requirement. Do you want to express that the ALTO protocol must return his full database if the data field is empty? Then, where is the guidance?
      ========
      Editorial suggestions. No need to respond to these; take them or modify them as you please:
      (4 items)
    3. Adrian Farrel: Discuss [2012-05-08]:
      In general I support this document, but I have a number of points that need to be looked at before publication. A couple of them are significant enough to merit points in this Discuss. The rest would not normally result in a Discuss, but I do feel that the volume of issues and the large number of Comments from other ADs suggest the need to carefully revise the whole document.
      Section 3.1 needs to discuss manageability requirements for the new protocol(s). RFC 5706 may give you some guidance.
      REQ. ARv14-28: Two issues here:
      1. This is a very solutions-oriented requirement. Shouldn't you actually state the functional requirements that would lead a protocol designer to either re-invent many of the features of TCP or to specify the use of TCP?
      2. Whatever happened to SCTP?
      3.2 does not appear to support an alto client being configured with the location of one or more alto servers. Shouldn't you allow that? That would seem to mean that it is not a requirement that every alto client be able to use discovery.
      But, in any case, REQ. ARv14-35 seems to be about implementation, not about protocol design.
    4. Adrian Farrel: Comment [2012-05-08]:
      Although not part of the Discuss, I would strongly recommend that you work through these Comments before publication.
      (10 items)
    5. Stephen Farrell: Discuss [2012-05-09]:
      I'm a bit confused by what might be a conflict between sections 3.3 and 5.2. The former says that nothing is mandatory-to-use, but the latter says that "neither the ALTO server nor a third party using or misusing the ALTO service should be able to infer the application behavior, e.g., who is exchanging which files with whom using a P2P file sharing application." I can't see how the latter can be guaranteed if the former is true. (And as a side-issue, maybe s/should/SHOULD/ above.)
    6. Stephen Farrell: Comment [2012-05-09]:
      It's surprising that most of the text in section 5 is about protecting the operator's interests. If that's just because the user's interests are taken as given, that might not be a good plan, since people might point back at this document and draw some conclusions from the relative amounts of text.
    7. Brian Haberman: Comment [2012-05-02]:
      I agree with Barry that some of the requirements should be re-worded. Otherwise, I have no issues with publishing this document.
    8. Barry Leiba: Comment [2012-04-28]:
      Substantive suggestions; please adopt or respond to these:
      "REQ. ARv14-9: An ALTO client protocol specification MUST define mechanisms, which can be used by the ALTO client to indicate"
      This looks like it was meant to be restrictive, not non-restrictive (as it's written). Need to remove the comma and preferably change "which" to "that". This applies to Req 16 also. This really is an important distinction in English, so please fix this. (You got it right in Req 8.)
      NEW: REQ. ARv14-9: An ALTO client protocol specification MUST define mechanisms that can be used by the ALTO client to indicate
      -- Req 13 --
      This isn't a requirement on the client protocol, but one on the client implementations. That's a different thing. I don't object to those being recorded in this document also, but they should be in a separate section, and not intermixed with protocol requirements. (The way Req 3 is written, it's that way as well, though it might best be rephrased to clearly be a requirement on the protocol.)
      -- Req 28 --
      Why is this a requirement? It may well be that the protocol(s) that get specified use TCP, but what's the reason to *forbid* the development of one that uses, say, SCTP?
      ========
      Editorial suggestions. No need to respond to these; take them or modify them as you please:
      (7 items)
    9. Pete Resnick: Discuss [2012-05-10]:
      1. In his Apps Directorate review <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03337.html>, Ted Hardie expressed concerns that some privacy issues are not properly addressed by this document. I agree, and these issues were not addressed in the latest revisions to the document. As he notes in particular:
      - I do not equate "disclosure of application behavior" to "disclosure of privacy sensitive user data", and I do not think the document is clear enough on this point.
      - Disclosure of aggregated data about queries is not addressed.
      2. I am not clear on the desirability of publishing this document at all. As is apparent from the discussion of Ted's review, there are places where the requirements document did not keep up with the actual completed protocol spec. (See discussion of ARv11-23 and ARv11-24.) That's fine, but it does make one question why this is being published once the spec is finished. Is there an expectation that future specs are going to have to rely on this document? As Enrico's response to Ted's review makes clear:
      "All in all, the document has been extremely useful, basically replacing the issue tracker tool the WG -- despite trying quite hard -- has never found a way to use effectively. The document has proved to be extremely useful in archival sense of recording and tracking the evolution of the ALTO protocol as it progressed in the WG and as new capabilities, actions and use cases were raised."
      If the issue tracker had been used instead of this document, there would be nothing to publish, and AFAICT, that would have been fine. Instead of fighting with this document to make it agree with the spec and cover cases that have been overtaken by events, why not drop it?
      I'm especially curious about the note in the shepherd report:
      "(1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
      "Strong consensus for publishing."
      Was there strong consensus for publishing because people thought this document would be of importance for people to read in the future in order to base work on it, or did people simply think that, "We've put so much work into this, we think it should be published."? I don't see a need to publish, and I'd like to hear some justification to do so.
    10. Pete Resnick: Comment [2012-05-09]:
      Please review Ted's other minor comments in his Apps Directorate review <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03337.html> and address as appropriate.

    Telechat:

  3. An Overview of the OAM Tool Set for MPLS based Transport Networks (Informational)
    draft-ietf-mpls-tp-oam-analysis-09
    Token: Adrian Farrel
    Note: Ross Callon (rcallon@juniper.net) is the document shepherd
    Discusses/comments (from ballot draft-ietf-mpls-tp-oam-analysis):
    1. Benoit Claise: Comment [2012-05-09]:
      - Thanks for this document, and specifically for the tables in section 4, as it's difficult to find his way in a world full of MPLS OAM RFCs (requirements, framework, Fault specific, Packet Loss and Delay, you name it). Along the same lines, I welcome http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-06, which has got a broader scope.
      "o The OAM toolset developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [RFC 5860]."
      Are you referring to http://tools.ietf.org/html/rfc5860#section-2.1.6
      "When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14])."
      The document would benefit from clearly identifying what you mean.
      This is even more confusing because you mention just below:
      The MPLS-TP OAM toolset is based on the following existing tools:
      o LSP-Ping as defined in [RFC 4379].
      o Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880] and refined in [RFC 5884].
      o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has been used for functionality guidelines for the performance measurement tools that were not previously supported in MPLS.
      It should be noted that certain extensions and adjustments have been specified relative to the existing MPLS tools, in order to conform to the transport environment and the requirements of MPLS-TP. However, compatibility with the existing tools has been maintained.
      "compatibility with the existing tools has been maintained" I guess that you meant the list above: LSP-Ping, BFD, Y.1731. So what about the delta from my previous point: VCCV, and VCCV-BFD?
    2. Adrian Farrel: Comment [2012-04-23]:
      Muly Ilan raised the following points on the MPLS list. They should be looked at:
      1. Table 2, second row - only Lock Instruct is G-Ach based. Loopback is a management command.
      2. Table 2, second row - LSP Ping is not related to Lock Instruct or loopback command.
      3. Table 2, third row - Lock Instruct is not indicated by a flag in AIS message and is not discussed in RFC6427.
      4. Section 5.2, third paragraph - need rewriting, per RFC6435 there's no loopback request message nor loopback response message.
    3. Stephen Farrell: Comment [2012-05-08]:
      (Oops wrong button, I've no objection really:-)
      - draft-ietf-mpls-tp-security-framework-02, May 2011 was updated by a -03 in October 2011.
      - weird references, the spaces muck up tools: [MPLS TP ITU Idents] [MPLS-TP Security Frwk]
      - s/MPSL-TP/MPLS-TP/ maybe?
    4. Barry Leiba: Comment [2012-04-29]:
      -- Section 7 --: "In addition to implement security protocol, tools, and mechanisms, following strict operation security procedures is very important, especially MPSL-TP static provisioning processes involve operator direct interactions with NMS and devices, its critical to prevent human errors and malicious attacks."
      This paragraph needs to be turned into more understandable English. I'd offer, but I don't understand what it's trying to say well enough to do it (hence, this comment). I suggest that it needs to be two or three sentences, rather than just one, and the grammar needs to be corrected so it's clear what it's saying. [I note that the rest of the document is fine to read; it's only this section that has any notable problem.]
      The next paragraph also has a couple of minor grammatical errors, but it's understandable:
      OLD: Since MPLS-TP OAM uses G-ACh, the security risks and mitigation described in [RFC 5085] apply here. In short, the G-ACh could be intercepted, or false G-ACh packets could be inserted. DoS attack could happen by flooding G-ACh messages to peer devices. To mitigate this type of attacks, throttling mechanisms can be used. For more details, please see [RFC 5085].
      NEW: Since MPLS-TP OAM uses G-ACh, the security risks and mitigation described in [RFC 5085] apply here. In short, the G-ACh could be intercepted, or false G-ACh packets could be inserted. DoS attacks can be mounted by flooding G-ACh messages to peer devices. To mitigate this type of attack, throttling mechanisms can be used. For more details, please see [RFC 5085].
    5. Martin Stiemerling: Comment [2012-05-07]:
      Section 8., paragraph 3:
      "Thanks to Rui Costa for his review and comments which helped improve this doecument."
      s/doecument/document/

    Telechat:

  4. Content Splicing for RTP Sessions (Informational)
    draft-ietf-avtext-splicing-for-rtp-07
    Token: Gonzalo Camarillo
    Note: Magnus Westerlund (magnus.westerlund@ericsson.com)  is the document shepherd.
    Discusses/comments (from ballot draft-ietf-avtext-splicing-for-rtp):
    1. Stewart Bryant: Discuss [2012-05-10]:
      Given that advertisement insertion in IPTV seems to be a deployed technology, and given that there are television SDOs working on IPTV, I would like to understand what input those SDOs and vendors had into this requirements set.
      Although this is a requirements specification, it seems to go into implementation detail, for example section 4.1
      There needs to be considerably more thought given to the security model to protect both the content provider and the viewer.
      Given the large number of comments and discusses, I request that a future revision of this document is brought back to the IESG for review.
    2. Benoit Claise: Comment [2012-05-10]:
      Much has been said already with the multiple DISCUSS feedback on this draft. So, no need to repeat the information: I'll trust the other ADs will take care of this one.
    3. Wesley Eddy: Comment [2012-05-09]:
      I support Stephen's DISCUSS points.
      REQ-3 seems broad and unspecific given the range of RTP/RTCP extensions. REQ-4 is vague on what it really means technically, and REQ-5 is also vague in regards to what the performance consists of and lacks rationale for why it needs to be relayed back. REQ-6 seems misformatted.
      As written, I do not think this document is useful to be permanently published as an RFC. It starts with the assumption that splicing is necessary for some use case and doesn't consider whether other approaches can meet the same actual requirements (of the use case, NOT of the splicing solution chosen). It recommends a solution without clearly comparing any alternatives.
    4. Adrian Farrel: Comment [2012-05-10]:
      In view of the large number of Discuss and Comment issues raised, I am not going to spend time reviewing this version of the document. If the document returns to a future telechat I will review it then.
    5. Stephen Farrell: Discuss [2012-05-09]:
      - REQ-4: What exactly does it mean to say that the splicer must be trusted by the receiver? I would have guessed that most receivers would not know of the splicer's existence. The reason this is a discuss is that I am worried that the consequences of treating a "transparent proxy" (as they're called in HTTP) as if it were "trusted" could be damaging to the Internet.
      - REQ-4 and REQ-6 seem to me to be in conflict. How can a receiver "trust" a splicer and yet be prevented from knowing what the splicer has done?
      - From the above, it seems to me that if there are any security requirements here then the receiver needs to have a direct relationship with the splicer, as does the sender, so that e.g. any encrypted traffic is decrypted at the splicer, and then re-encrypted.
      - Is the text in the 1st two paragraphs of 4.2 saying that we are encouraging hosts on the Internet to fool one another and engineering our protocols to make it harder for some of them to figure out they are being fooled? That doesn't seem like a good goal to me, without a lot more justification.
      - Changes to RTCP reports and loss values as suggested here would also seem to preclude any real e2e security. I just don't get why that is ok.
      - If so-called "user invisibility" is required (and there is no REQ-X for that) and it has the consequence of creating loops then that ought be described, and it isn't.
      - If "invisible" splicing were really possible, then how could any supposedly "secure" RTP session ever be trusted by a receiver?
    6. Stephen Farrell: Comment [2012-05-09]:
      section 1:
      - s/into internet/into the Internet/
      - s/changes to transport layer/changes to the transport layer/
      - s/requirements of RTP splicing/requirements for RTP splicing/
      - REQ-1, what environments other than unicast or multicast might exist? If this isn't a tautology then I don't know what's meant.
      - REQ-3, I'm not clear what backward compatible means here - the splicer seems to be talking RTP/RTCP for both main and current content in Figure 1, so what element of backward compatibility is meant here?
      - Is the reference to SCTE30 meant to be the 2001 version? I only found the 2009 version on scte.org, but didn't hunt much. For SCTE35 2007 is referenced, but there's a 2011. What's up there? Stable URLs for those and the ISMA document would be good.
    7. Barry Leiba: Comment [2012-04-30]:
      Substantive but non-blocking comments; please adopt or respond to these:
      -- General --
      I see from the mailing list discussion that there had been some consideration of using an RTP translator, rather than an RTP mixer. It appears that mixer was chosen more or less by default -- there was a concrete proposal for it, and none for the other. Given that, it might be nice to have a few words (maybe a small section at the end, maybe an appendix, something like that) about the possibility of using an RTP translator, and why using a mixer is better. If the WG considered the issue, others are likely to as well. But feel free to respond, "Yes, it might, but that is not this document." :-)
      -- Abstract --
      You talk about proposing the use of "an existing RTP level middlebox", and you do know what that middlebox is. I suggest saying so. Maybe like this:
      NEW: and analyze whether an RTP mixer (an existing RTP level middlebox) can meet these requirements. Finally, we provide concrete guidelines for how the RTP mixer can work to handle RTP splicing.
      You might also mention this in the last paragraph of the Introduction.
      -- Section 4 --
      Where is an "RTP mixer" defined? Should there be a reference? I don't see a definition in RFC 3550 -- the term is used there, but not defined.
      I also suggest expanding SSRC and CSRC on first use.
      -- Section 4.1 --
      I really dislike the odd "pseudo-code" format to illustrate the process. It's already more prose than pseudo-code, and I strongly urge you to re-cast it as normal text.
      -- Security Considerations --
      The first paragraph is a little fluffy about what the issue is. What makes "regular transport security mechanisms" different here... that is, what's the *real* point? Is it that end-to-end encryption makes it impossible for the middlebox to play with the stream, but hop-by-hop encryption allows it? I'd like to see this be clearer about what the conditions are that makes this feasible vs impossible, and then whether there are any security issues involved with allowing a middlebox to replace parts of the stream. (It's possible that there are none, when the trust model in the second paragraph is correct.)
      ========
      Editorial suggestions. No need to respond to these; take them or modify them as you please:
      (3 items)
    8. Pete Resnick: Discuss [2012-05-09]:
      This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear what the meaning is (i.e., not just grammatical mistakes which we see in all documents) indicates to me that it did not have sufficient review.
      I don't think REQ-2 is an actionable protocol requirement. Given section 4.3, it appears that what you mean by REQ-2 is something like, "Make the sound and picture change be smooth", in which case it's not a protocol requirement at all. Making the media transition be smooth involves a great deal of knowledge about the nature of the media being sent. You may need to do fading, or some other thing to make sure that the boundary between the main media and the substitutive media is seamless. There's nothing to be done in protocol for this; you have to know something about the media itself. And it is hard to reconcile this with the statement in section 4 which says, "splicing is not a very complicated processing". Presumably REQ-2 is not really about the buffering, which should not be an issue at all because you are presumed to already know when splicing begins and ends:
      "The methods how Splicer learns when to start and end the splicing is out of scope for this document."
      So you should already know where you're going to start inserting your data into the stream.
      REQ-6 is not a requirement at all. First, as Stephen says, it conflicts with REQ-4. But even beyond that, the body of the requirement is basically saying, "Do it if it is convenient." The document does no analysis as to the effectiveness of the "trade-off" invisibility (simply maintaining RTP header params) to see if it's even worth doing so. I don't see what an implementer reading REQ-6 would do.
    9. Pete Resnick: Comment [2012-05-09]:
      4.1 - I don't see what the first paragraph is telling anyone. Presumably if you are a splicer, you know that you will need data to insert into the stream and that it will be coming from somewhere. What is the purpose of the first paragraph?
      Paragraph 2 starts, "Even if splicing does not begin". Do you simply mean, "Before splicing begins"? Otherwise, I don't understand what this sentence is saying. Also, unlike the rest of the paragraphs, it does not talk about "encapsulating". I assume it should, yes?
      Paragraph 3 only mentions a substitutive RTP stream and not local media.
      I agree with Barry that the pseudo code is useless, if not just confusing, and should be removed. The prior text should include all of the information that would have been in the pseudocode.
      "Note that, the substitutive content should be outputted in the range of splicing duration."
      I do not understand the above sentence.
      4.3 - "If the time slot for substitutive RTP stream mismatches (shorter or longer than) the duration of the reserved main RTP stream for replacing, the media clipping may occur at the splicing point which usually is the joint between two independently decodable frames."
      I understood everything up to the word "which", but I don't understand the importance of what comes after that. But even before that, I'm not clear on whether you mean "clipping" or simply "truncation". The last paragraph of 4.3 seems to talk about true clipping, but the rest of this seems to be about extending media that does not fill a time slot or truncating media which overfills a slot and how to make those transitions look smooth. I wouldn't call all of these "clipping".
    10. Robert Sparks: Discuss [2012-05-08]:
      (Clearing up some minor typos to make these easier to read)
      It's not clear what a mixer implementer should be doing with the advice in the last full paragraph on page 12. How is that implementer supposed to apply something like RFC5348 or RFC5762? Is this feedback running between the mixer and the receiver, the mixer and the source, or something else? In any case, it should be made explicit that this isn't asking the mixer to begin transcoding.
      The pseudo code blocks each say "the timestamp of the current RTP packet increments linearly" and that is unclear. Is this trying to say that the mapping from the timestamp in the input packet to the mixer and the output packet be linear?
      The implementations considerations section says there is a potential issue with loop detection, but doesn't actually describe the issue, or how satisfying the user invisibility requirement makes it more likely to occur.
      The document should be explicit about the expected trust model if SRTP is used. I believe it is currently assuming that media from either source would be decrypted at the mixer and re-encrypted towards the receiver(s). The first paragraph in section 6 could be read to imply that the mixer is just forwarding SRTP packets.
    11. Robert Sparks: Comment [2012-05-08]:
      When considering the clarification for the first point above, consider making the first two paragraphs of section 4.2 clearer as well.
      CSRC is typo'd as CRSC in a few places.
    12. Martin Stiemerling: Discuss [2012-05-07]:
      Section 4.1., paragraph 3:
      "When splicing begins, mixer chooses the substitutive RTP stream as input stream at splicing in point, and extracts the payload data (i.e., substitutive content). After that, mixer encapsulates substitutive content instead of main content as the payload of the current media stream, and then outputs the current media stream to receiver. Moreover, mixer may insert the SSRC of substitutive RTP stream into CSRC list in the current media stream."
      What happens if the payload of the received substitutive RTP stream is larger than the maximum RTP payload of the outgoing RTP stream?
    13. Martin Stiemerling: Comment [2012-05-07]:
      General comment: This document is in need of a lot of language improvements, e.g., replacing 'Splicer' with 'the Splicer' all over to improve readability. It seems that almost no articles have been used. This makes reading the text very, very hard, at least for me as non-native speaker.
      (13 items)
    14. Sean Turner: Comment [2012-05-10]:
      I support the discuss positions from the other ADs.

    Telechat:

  5. Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method (Informational)
    draft-ietf-avtext-rams-scenarios-05
    Token: Gonzalo Camarillo
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-avtext-rams-scenarios):
    1. Stephen Farrell: Comment [2012-05-09]:
      I agree with the secdir review and Barry's comment about the security considerations and believe this is being handled already.
    2. Russ Housley: Comment [2012-05-06]:
      Please consider the editorial issues raise in the Gen-ART Review by Vijay Gurbani on 27-Apr-2012.
    3. Barry Leiba: Comment [2012-04-29]:
      Substantive comments; please adopt or respond to these:
      This seems to be a well written document.
      Security Considerations:
      Might it not be better to say something like this?:
      "Because this document describes deployment scenarios for RAMS, all security considerations are specified in the RAMS specification [RFC6285]."
      ========
      Editorial suggestions. No need to respond to these; take them or modify them as you please:
      IANA Considerations: You might add an RFC Editor note to remove this section prior to publication, which is the normal practice for "empty" IANA Considerations sections.
    4. Martin Stiemerling: Comment [2012-05-07]:
      A good document and I have one substantial comment to be addressed:
      It is required to add a reference to RFC 6285 about the discussion of RAMS potentially causing congestion. The place to add this would be in the beginning of Section 5. "FEC during RAMS and Bandwidth Issues". Otherwise, Section 5 is sort of incomplete, as it suggests that RTP sender and receiver have alway full knowledge about the state of the network path between both. RFC 6285 is documenting the challenges nicely.

    Telechat:

  6. Multicast Addresses for Documentation (Informational)
    draft-ietf-mboned-mcaddrdoc-03
    Token: Ronald Bonica
    Note: Lenny Giuliano (lenny@juniper.net) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-mboned-mcaddrdoc):
    1. Stewart Bryant: Comment [2012-05-10]:
      "The use of specific multicast addresses for documentation purposes has no impact on security."
      Actually isn't it a security improvement?
    2. Benoit Claise: Comment [2012-05-07]:
      I would propose one text improvement:
      OLD: GLOP [RFC3180] is a method for deriving IPv4 multicast group addresses from 16 bit AS numbers.
      NEW: GLOP [RFC3180] can be used by anyone who owns a registered AS number to derive 256 global multicast addresses, by mapping the AS number in the middle 16 bits of the IPv4 multicast address 233/8.
    3. Adrian Farrel: Discuss [2012-05-03]:
      The authors have agreed to update the IANA section following the Routing Directorate review by Geoff Huston and email exchanges with IANA. This Discuss holds the document until that update has been done.
    4. Brian Haberman: Discuss [2012-04-30]:
      I support the publication of this document, but I think there are a few things that should be DISCUSSed.
      1. Should IANA reserve the multicast addresses that are constructed from the unicast prefixes allocated for documentation use? For example, should FF3X:20:2001:DB8::/64 be reserved?
      2. Was there any consideration given for how permanent IPv6 multicast addresses could be represented in documentation (i.e., flag T=0)?
    5. Brian Haberman: Comment [2012-04-30]:
      1. This draft states that for IPv4, 233.252.0.0/24 is reserved for documentation. The IANA registry lists that range as being assigned to MCAST-TEST-NET. Should this description be updated to reflect its new use as a documentation range?
      2. It may be useful for the draft to mention why the IPv6 address request to IANA is for a /96. Referencing RFC 3307 and its method of allocating the lowest 32-bits of multicast addresses would be sufficient.
    6. Pete Resnick: Comment [2012-05-09]:
      I won't object given that RFC5737 and RFC3849 were both Informational, but shouldn't this kind of thing be BCP?
      I agree that the IANA Considerations section needs serious rewriting. It needs to include the list of reserved addresses.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. The Reasons for Selecting a Single Solution for MPLS-TP OAM (Informational)
    draft-sprecher-mpls-tp-oam-considerations-03
    Token: Adrian Farrel
    Note: Ross Callon (rcallon@juniper.net) is the document shepherd.
    Discusses/comments (from ballot draft-sprecher-mpls-tp-oam-considerations):
    1. Benoit Claise: Comment [2012-05-09]:
      Thanks for the document.
      Three editorial points:
      - Transport profile -> Transport Profile
      - "It is possible to argue that using MPLS for Transport is only a stepping stone in the middle of a longer transition."
      Transport -> transport or Transport Profile?
      - "As we shall demonstrate, ..."
      The RFC editor gave me in the past the advice to remove "we", "us", "our" from the future RFCs.
    2. Stephen Farrell: Comment [2012-05-08]:
      I fully support the conclusion here and the argument varies from compelling at best to good enough at worst.
      typos:
      s/documentationin/document in/?
      s/viably/viability/
      s/a E1 only/an E1 only/
    3. Russ Housley: Comment [2012-05-06]:
      Section 7 should be removed before publication as an RFC.
      The Gen-ART Review by Brian Carpenter reported one editorial problem. There is duplicated text in section 1.2:
      "... be managed using tools with similar look and feel. The requirements specifications [RFC5654] and [RFC5860] specifications [RFC5654] and [RFC5860] capture the essential issues that must be resolved to allow ..."
    4. Barry Leiba: Comment [2012-05-02]:
      Excellently written, clear document.
      Just a few minor editorial things; no need to reply to them:
      (four items)

    Telechat:

  2. Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) (Informational)
    draft-betts-itu-oam-ach-code-point-04
    Token: Adrian Farrel
    Note: Huub van Helvoort (Huub.van.Helvoort@huawei.com) is the document shepherd.
    Discusses/comments (from ballot draft-betts-itu-oam-ach-code-point):
    1. Ronald Bonica: Comment [2012-05-09]:
      As others have said, the specification of multiple OAM mechanisms for MPLS-TP does not benefit the community. However, I will not block publication of this draft.
    2. Stewart Bryant: Comment [2012-05-10]:
      This document states that:
      "A number of experts in the IETF do not consider that the development or deployment of a second protocol solution within the same architectural problem space is necessary or advisable" and cites draft-sprecher-mpls-tp-oam-considerations.
      draft-sprecher-mpls-tp-oam-considerations provides many engineering reasons why the deployment of a second MPLS-TP OAM is undesirable.
      If G.8113.1 were an IETF document I would have entered a Discuss on this enabling document. However, I believe that it is in the best interests of the IETF that this decision be deferred to the government officials charged with the responsibility for the approval or rejection of ITU-T Recommendation G.8113.1 itself. I request that in applying their wisdom to this difficult problem, these government officials do due diligence to the engineering consequences of their actions.
      I have thus entered an abstain.
    3. Benoit Claise: Comment [2012-05-10]:
      The experts believe that multiple OAM protocols for MPLS-TP is undesirable for interoperability, and I agree with that. However, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1.
    4. Ralph Droms: Comment [2012-05-09]:
      I agree with the experts in the IETF cited in this document and with the conclusion reached in other documents that it would be desirable to have only one MPLS-TP OAM protocol. Therefore, in my opinion, a new G-ACh Type should not be assigned for "G.8113.1 OAM" as requested in this document. However, I will not block its publication and I have entered an Abstain position.
    5. Wesley Eddy: Comment [2012-05-09]:
      In the IANA considerations where the value 0x8902 is suggested, it would probably be good to note that the rationale is to be consistent with the EtherType for Y.1731. If that value does get assigned, I think it would be good to have record of why such a seemingly odd value was picked since there are several earlier blocks of unassigned values.
      I agree with other ADs that the IETF participants have not expressed a favorable consensus for making an allocation permitting multiple OAM types.
    6. Stephen Farrell: Comment [2012-05-08]:
      (This is an agreed text between the two security ADs, in case there's a concern its a cut'n'paste error.)
      While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15 did approve the contents of RFC 5586 and in that RFC it requires that relevant associated channel type specification include security considerations. The latest version of G.8113.1 available to me does not include a security considerations section. It's unclear why G.8113.1 doesn't include the agreed to section.
      If G.8113.1 was an IETF draft, I would have entered this as a Discuss because G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223). Further, as there are two OAM solutions I consider the one that does address security considerations to be the superior solution. In addition, experience in the Security Area has shown developing two standards for the same thing is damaging and that that damage persists in the long term, so I believe that the current situation with two OAM solutions represents a bad outcome.
      However, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1 based on this point.
    7. Russ Housley: Comment [2012-05-07]:
      I believe that multiple OAM protocols for MPLS-TP is undesirable; however, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1.
    8. Pete Resnick: Comment [2012-05-08]:
      We have a situation here where we are being asked for IETF-wide approval of a code point allocation for a protocol that we have never seen, and a protocol that the present document says "a number of experts in the IETF" think is not "advisable". Though there was minimal objection during IETF Last Call, I'm not completely convinced we would have considered this "in the rough" part of the rough consensus under normal circumstances. However, I think calling it "rough consensus" can be justified, and therefore I'm uninclined to argue about it further. That said, I abstain.
    9. Robert Sparks: Comment [2012-05-09]:
      I don't believe what this code point represents is in the best interest of the Internet, but also don't believe further changes to this document will improve the situation so I am abstaining.
    10. Sean Turner: Comment [2012-05-07]:
      While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15 did approve the contents of RFC 5586 and in that RFC it requires that relevant associated channel type specification include security considerations. The latest version of G.8113.1 available to me does not include a security considerations section. It's unclear why G.8113.1 doesn't include the agreed to section.
      If G.8113.1 was an IETF draft, I would have entered this as a Discuss because G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223). Further, as there are two OAM solutions I consider the one that does address security considerations to be the superior solution. In addition, experience in the Security Area has shown developing two standards for the same thing is damaging and that that damage persists in the long term, so I believe that the current situation with two OAM solutions represents a bad outcome.
      However, I do not think it is in the best interest of the IETF to block the allocation of the code point for ITU-T Recommendation G.8113.1 based on this point.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. Probabilistic Routing Protocol for Intermittently Connected Networks (Experimental)
    draft-irtf-dtnrg-prophet-09
    Token: Adrian Farrel
    Note: IRTF Submission. Stephen Farrell (stephen.farrell@cs.tcd.ie) is the document shepherd.
    Discusses/comments (from ballot draft-irtf-dtnrg-prophet):
    1. Stewart Bryant: Comment [2012-05-10]:
      I thought that this was an interesting and novel experimental routing protocol and am thus voting yes.
      I intend to read it in close detail a further time, and if I have any comments that may improve the text, I will pass them to the authors and ISE.
    2. Benoit Claise: Comment [2012-05-10]:
      Slightly surprised by "No objections to its publication as an RFC were raised." in the abstract! If it passes the IESG, it's because no objections were raised. So it doesn't make sense in the abstract of this future RFC ;-)
      Along the same lines, not sure if it's appropriate to have the following sentence in the abstract: "This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group." The RFC-editor should take the final decision on this one.
    3. Adrian Farrel: Comment [2012-04-30]:
      The following comments are provided for consideration by the ISE and document authors in case they can be used to improve the document.
      I think that some clarity could be added to the IANA work by clarifying the meaning of "Experimental" ranges and other ranges (using the 5226 allocation policies) in the light of this document itself being an Experimental document.
      PRoPHET is an Experimental protocol. That is good. Implementers and researchers would benefit from some description and advice on how best to experiment with the protocol. What constraints should be applied in terms of interaction with "the Internet"? What sort of information should experimenters be hoping to gather? What further protocol work is needed? How would we assess whether PRoPHET is worthy of standardising?
    4. Stephen Farrell: Comment [2012-05-08]:
      For this I'm either yes or else I recuse if that's the proper thing for an IRSG member and RG co-chair to do. I guess nobody knows (or cares:-) so I'll at least temporarily set a positive precedent.

    Telechat:

3.3.3 For Action

  1. IPv6 Nonce Destination Option for ILNPv6 (Experimental)
    draft-irtf-rrg-ilnp-noncev6-02
    Token: Brian Haberman
    Note: Tony Li (tony.li@tony.li) is the document shepherd.

    Telechat:

  2. ICMP Locator Update message for ILNPv6 (Experimental)
    draft-irtf-rrg-ilnp-icmpv6-02
    Token: Brian Haberman
    Note: Tony Li (tony.li@tony.li) is the document shepherd.

    Telechat:

1254 EDT break

1300 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. Worthwhile Extensible Internet Registration Data Service (weirds)
    Token: Pete

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

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

    Telechat:

  2. Web Authorization Protocol (oauth)
    Token: Stephen

    Telechat:

  3. Diameter Maintenance and Extensions (dime)
    Token: Benoit

    Telechat:

  4. Network File System Version 4 (nfsv4)
    Token: Martin

    Telechat:

  5. Multipath TCP (mptcp)
    Token: Wes

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Approval of designated expert for IMAP Response Codes registry (Barry)

    Telechat:

  2. Dan Ramascu has posted an IESG response to the IEEE Liaison

    Telechat:

7. Agenda Working Group News

1425 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-05-10 07:30:03 PDT)

draft-ietf-roll-minrank-hysteresis-of

  1. Ralph Droms: Discuss [2012-05-10]:
    These Discuss points are all intended to ask about design
    decisions and suggest clarifications.  No action is required
    by the authors until these points have been discussed.
    
    (Updated at last edit with points 6 and 7.)
    
    1.  Why is one objective function defined for several potential
    metrics?  The details of MRHOF seem to preclude the establishment of
    several RPL instances in an LLN, each of which uses MRHOF with a
    different selected metric.
    
    2. How are the nodes in the RPL instance informed about the selected
    metric?  My understanding of RPL is that only the objective function
    is included in the DIO received as an advertisement for a particular
    RPL instance, which means a node can't know the selected metric for
    that RPL instance and can't meaningfully decide among multiple RPL
    instances all using MRHOF as the objective function.
    
    As a followup to (1), if there were a way to encode the selected
    metric for a RPL instance in the DAO, a node would be able to select
    which RPL instance to use for a particular type of traffic.
    
    3. Based on (1) and (2), would configuration and selection issues be
    ameliorated if the five candidate selected metrics were each asssigned
    a separate objective function?  Use of a separate OF code point for
    each of the five possible selected metrics would allow multiple RPL
    instances.
    
    4. Related to the above, I don't see anything in section 6 about
    managing the selected metric.  Don't all of the nodes that join a RPL
    instance using MRHOF have to be configured to use the same selected
    metric?
    
    5. In section 3.2.2:
    
       a
       node MAY use a different objective function to select which of these
       neighbors should be considered to have the lowest cost.
    
    seems to contradict the statement in the Introduction that "all nodes
    in a network use a common OF."  Should "different objective function"
    be replaced with "some other selection criteria?"
    
    6. In section 5, are the RECOMMENDED values appropriate for all
    selected metrics or just for ETX?  Are there any references that might
    be cited that would give background on the working group experience
    with ETX and the development of the recommended values?
    
    7. In section 6.1, why not "MUST support the DODAG Configuration
    option?"  I don't see any RFC 2119 requirements on the implementation
    of the DODAG Configuration option (which would appera to be an
    oversight), but I don't understand how a node can operate in a RPL
    instance without, for example, being able to determine the Objective
    Function used by that instance.
    
  2. Ralph Droms: Comment [2012-05-10]:
    These Comment points are non-blocking editorial suggestions.
    
    1. In the Introduction, s/OF/objective function/ ; the abbreviation OF
    doesn't appear to be used anywhere else in the document.
    
    2. Is the second paragraph in section 3.1 equivalent to writing:
    
       If a non-root node does not have metrics to compute the path cost
       through any of the candidate neighbors, [...]
  3. Wesley Eddy: Comment [2012-05-09]:
    I support point 2 of Brian's DISCUSS.
  4. Stephen Farrell: Comment [2012-05-09]:
    - Hysteresis could do with a definition - many non-native
    English speakers (and native speakers!) might have to go
    look it up so why not save them the trouble?
    
    - ETX is used without expansion of reference in the intro.
    Link color is used in 3.3 but not defined. It'd be good to
    be clearer that those are defined in 6551.
    
    - This smells experimental to me. I wondered if it had
    already been implemented/tested. (Not a requirement
    for PS, so I'm just asking.)
    
    - You RECOMMEND use of security mechanisms if there is a
    risk. Can't you be more specific on which security
    mechanism you mean (e.g.  referring to the right bit of
    6550, maybe 10.6)? I've not made this a discuss since I
    hold one on the security framework and perhaps the
    inability to pick something concrete here will be resolved
    as a side-effect of that.
  5. Brian Haberman: Discuss [2012-05-02]:
    I found this draft to be rather straightforward to understand, but have a few
    points I would like clarified (possibly just for me)...
    
    1. In sections 3.1 and 3.2.1, the draft says that messages can be delayed but
    should not be delayed too much?  How much is too much?  Is it dependent on the
    metric being used?  Are there guidelines that should be provided?  If different
    implementations try to interact, will their selection of delay values hinder
    performance/stability of the RPL-based network?
    
    2. Section 5 says, "The best values for these parameters should be
    experimentally determined."  Is this guidance to implementers to figure out what
    values to support in their implementation or advice to operators to test a range
    of values for their particular deployment?  As a standards-track document, this
    type of nebulous statement concerns me from a variety of perspectives.
    
    3. Section 8 asks IANA to allocate a code point, but where in the draft is that
    code point used? Is it used as a part of the transmission logic in section 3.4?
    
  6. Brian Haberman: Comment [2012-05-02]:
    I support Barry's comment on the confusing use of SHOULDs+MAYs and would like to
    see those cleaned up.
    
    1. The Introduction uses several acronyms without any expansion (OF, DAG, ETX).
    These should be expanded on first use and possibly augmented with a reference
    (e.g., ETX).
    
    2. Section 3.1 uses DODAG with no expansion or reference.
    
    3. A forward pointer to section 5 in section 3.2.2 would make sense for the
    constants/variables referenced.
  7. Russ Housley: Comment [2012-05-06]:
      Please consider the editorial issues raise in the Gen-ART Review by
      Miguel Garcia on 27-Mar-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07303.html
  8. Barry Leiba: Comment [2012-04-29]:
    Substantive comments; please adopt or respond to these:
    
    Nice, easy-to-read document.  Only one substantive comment, about 2119 language:
    
    -- Section 3.2.1 --
    
    The use of SHOULD and MAY here is inconsistent -- the MAY turns the SHOULD into
    something more optional than a SHOULD ought to be.  I suggest not using MAY, and
    rephrasing this way (unless I misunderstand the meaning here):
    NEW
       If,
    despite the above, it is necessary to defer the parent selection
       until a
    later time, note that doing so can delay the use of better
       paths available
    in the network.
    
    ========
    Editorial suggestions.  No need to respond to these; take them or
    modify them as you please:
    
    -- Section 1 --
       Because MRHOF seeks to minimize path costs as described by metrics,
       it can only be used with additive metrics.  MRHOF ignores metrics
       that are not additive.
    
    Is it really "ignores"?  Or "does not support"?
    
    -- Section 2 --
    OLD
             Path cost is obtained by summing up the selected metric of the
             links or nodes along the path.
    NEW
             Path cost is obtained by summing up the values of the selected
             metric for the links or nodes along the path.
  9. Robert Sparks: Comment [2012-05-07]:
    I made the same observations in my review that Barry reports in his comments.
    Please also consider clarifying that no one node sums up the values of the
    selected metrics in the definition of path cost - rather, each node adds to the
    cost reported by the parent (section 3.1) resulting in a total for the path.
  10. Martin Stiemerling: Discuss [2012-05-07]:
     Section 3., paragraph 1:
    
    >    This computation MAY also be performed periodically.  Too much delay
    >    in updating the path cost after the metric is updated or a new metric
    >    advertisement is received can lead to stale information.
    
      Is there any recommendation or further reading on what the time is
      to be
    used to perform the periodically updates?
      Re-computing state periodically
    might be a good thing, but I would expect that a Standards Track document is
    much more specific on this.
    
    Section 2., paragraph 1:
    
    >    The parent selection MAY be deferred until a later time.  Deferring
    >    the parent selection can delay the use of better paths available in
    >    the network.
    
      How much is the 'later time'?
      I would expect that a Standards Track document
    is much more specific on this, other than do whatever you think is appropriate.
    
    Section 5., paragraph 9:
    
    >    The parameter values are assigned depending on the selected metric.
    >    The best values for these parameters should be experimentally
    >    determined.  The working group has long experience routing with the
    >    ETX metric.  Based on those experiences, these values are
    >    RECOMMENDED:
    
      Is there any reference on how the WG came to the below numbers? This
      would be good for people trying to follow this up in the future. They
      might need to know how to came to these numbers.
    
  11. Martin Stiemerling: Comment [2012-05-07]:
    - I support Barry's comment on SHOULD/MAY usage
    - More points here:
    
    Section 1., paragraph 1:
    
    >    An objective function specifies how RPL [RFC6550] selects paths.  For
    >    example, if an RPL instance uses an objective function that minimizes
    >    hop-count, RPL will select paths with minimum hop count.  RPL
    >    requires that all nodes in a network use a common OF; relaxing this
    >    requirement may be a subject of future study.
    
      Expand abbreviation OF on first use.
    
    Section 1., paragraph 4:
    
    >    This specification describes MRHOF, an objective function for RPL.
    >    MRHOF uses hysteresis while selecting the path with the smallest
    >    metric value.  The metric that MRHOF uses is determined by the
    >    metrics in the DIO Metric Container.  For example, the use of MRHOF
    >    with the latency metric allows RPL to find stable minimum-latency
    >    paths from the nodes to a root in the DAG instance.  The use of MRHOF
    >    with the ETX metric allows RPL to find the stable minimum-ETX paths
    >    from the nodes to a root in the DAG instance.  In the absence of a
    >    metric in the DIO Metric Container or the lack of a DIO Metric
    >    Container, MRHOF defaults to using ETX to compute Rank, as described
    >    in Section 3.5.
    
      Expand abbreviation MRHOF on first use (sort of first in the
      introduction). Expand DAG and ETX on first use, probably add
      reference.

draft-ietf-appsawg-mime-default-charset

  1. Adrian Farrel: Comment [2012-05-05]:
    I struggled a bit with the escape clauses for the "SHOULD" statements, but I
    think I got it straight, and I support the publication of this document.
  2. Stephen Farrell: Comment [2012-05-09]:
    I'm a bit confused here, and would like to check how
    much:-)
    
    Old subtypes use ascii as a default but don't say that
    explicitly and will not be changed by this RFC. New
    subtypes SHOULD NOT define a default. So when I go look at
    the registry do I need to compare the date of registration
    vs. the date of this RFC to know what's what?
  3. Russ Housley: Comment [2012-05-06]:
      Please consider the editorial issues raise in the Gen-ART Review by
      Vijay Gurbani on 27-Apr-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07401.html

draft-ietf-ippm-reporting-metrics

  1. Benoit Claise: Comment [2012-05-10]:
    - Please address the OPS-DIR review by Bert Wijnen
    
        The one thing that concerns me a little bit is the fact that this
        document uses RFC2119 language. I think that is in-appropriate.
        Using lower case for the MUST, SHOULD and RECOMMEND in the document
        is perfectly fine I think. 
    
    - Support Adrian's comment regarding the title "Reporting IP Network Performance
    Metrics: Different Points of View"
    
    -  Next to the question "How will the results be used?", it would have been
    nice to ask the question "Which audience will read the results"
    Network
    Characterization = network operator
    Application Performance Estimation =
    application designer, service developer, etc..
    Actually, this is what you did,
    without clearly mentioning it, asking the question about "how", and answering
    with "two main audience categories"
    
    -
    
       2.  Application Performance Estimation - describes the network
           conditions in a way that facilitates determining affects on user
           applications, and ultimately the users themselves.  This point-
           of-view looks outward, toward the user(s), accepting the network
           as-is.
    
    What do you mean "accepting the network as-is."?
    It's not because the results
    will be used for application performance estimation that you can't optimize your
    network.
    
    - "The scope of this memo primarily covers the design and reporting of
       the loss and delay metrics [RFC2680] [RFC2679]."
    
    What do you mean by design of metric? Do you mean choosing the measurement
    characteristics of a metric?
    Note: multiple occurrences of "metric design" in
    the draft.
    
    -  Section 2
       "These memos effectively describe two
       different categories of metrics,
    
       o  [RFC3148] includes restrictions of congestion control and the
          notion of unique data bits delivered, and
    
       o  [RFC5136] using a definition of raw capacity without the
          restrictions of data uniqueness or congestion-awareness.
    
       It might seem at first glance that each of these metrics has an
       obvious audience (Raw = Network Characterization, Restricted =
       Application Performance), but reality is more complex and consistent
       with the overall topic of capacity measurement and reporting.  For
       example, TCP is usually used in Restricted capacity measurement
       methods, while UDP appears in Raw capacity measurement. "
    
    I was not sure what you meant by Raw and Restricted.
    
    However, I saw a definition way down in the document, in section 6 and 7
       Raw capacity refers to the metrics defined in [RFC5136] which do not
       include restrictions such as data uniqueness or flow-control response
       to congestion...
    
       Restricted capacity refers to the metrics defined in [RFC3148] which
       include criteria of data uniqueness or flow-control response to
       congestion...
    
    Please add those "definitions" in section 2.
    It's specifically important since
    RFC5136 and RFC3148 don't mention Raw/Restricted
    
    - I learned to avoid "we", "our", "us" in RFCs.
    I double-checked if it's still
    the case with the RFC-editor. I will let you know the answer.
    
    - I would add an extra point to "For these and other reasons, such as"
    Something such as: 
    
            o the ability to drill down to a specific measurement interval for
    deeper analysis
    
    Justification: most of the time, when checking SLA, we check with large
    measurement interval, but want to ability to do a postmortem analysis
    
    - I don't understand
      "Fortunately, application performance estimation activities are not
       adversely affected by the estimated worst-case transfer time.  
       Although the designer's tendency might be to set the Loss Threshold
       at a value equivalent to a particular application's threshold, this
       specific threshold can be applied when post-processing the
       measurements. "
    
    - "We can say that the Delay and Loss metrics are Orthogonal"
    Orthogonal -> orthogonal?
    
    - section 7.4.  Bulk Transfer Capacity Reporting
    
       When BTC of a link or path is estimated through some measurement
       technique, the following parameters SHOULD be reported:
    
    Also transport type, link layer type, tunneling yes/no, etc...?
    
    - Personal preference, no need to modify the document unless you feel like it.
    All my customers are interested in delay, loss, and delay variation (jitter).
    It
    would have been nice to have a clear pointer in the table of content, with a
    clear entry "Effect of POV on the Delay Variation Metric . . . . . . . . . . . .
    . ." instead of addressing delay variation in "delay metric" section 5.1.3
    
    -
    
    Section 4.1 of [RFC3393] describes this specification and its
       rationale (ipdv
    = inter-packet delay variation in the quote below).
    Use IPDV (Remember you used
    Packet Delay Variation (PDV)) in the document, and refer to RFC5481
    Several ipdv
    instances in the draft.
    
    -
    
      "Network Characterization has traditionally used Poisson-distributed
       inter-packet spacing, as this provides an unbiased sample."
    
    Is this correct? or Poisson-distributed start, with fixed inter-packet spacing,
    to match, for example, a voice/video application
  2. Adrian Farrel: Comment [2012-05-05]:
    I have no objection to the publication of this document, but I think
    it would be helpful if the document title reflected the fact that the 
    metrics being reported are IP network performance metrics.Perhaps...
    
      Reporting IP Network Performance Metrics: Different Points of View
    
    I also have some small Comments as follows...
    
    ---
    
    I think the document would benefit from a further read-through to fix
    some of the English and readability issues.  Leaving these to the RFC
    Editor risks errors of meaning being introduced during the edit 
    process.
    
    ---
    
    Section 3.
    
       This section gives an overview of recommendations
    
    And...
    
    Section 3.1.
    
       This section gives an overview of reporting recommendations for the
       loss, delay, and delay variation metrics.
    
    But...
    
    Section 3.1
    
       The minimal report on measurements MUST include both Loss and Delay
       Metrics.
    
    This "MUST" is not a recommendation. You need to decide whether you are
    writing recommendations (which seems wholy appropriate since there are
    no operational or interop implications of missing out some measurements)
    or writing requirements.
    
    Notwithstanding the resolution of the above point, I am not convinced 
    that you really need to use RFC 2119 language in this document.
    
    ---
    
    Section 3.1
    
    "We have calculated a waiting time" needs a forward reference to the 
    place in the document where this calculation is performed.
    
    ---
    
    Section 3.1
    
    "99.9%-ile" is really ugly!
    
    ---
    
    A bit puzzled by Section 4.1.1 where you have
    
                n
               ---
               \
     D = t  +   >  (t  +  q )
          0    /     i     i
               ---
              i = 1
    
    Presume you decided to not consider queue at the source node because you
    consider it as the generator of the packets and not subject to queuing.
    This is slightly suspect in my opinion and depends on the nature of
    - the source node
    - the definition of the path.
    
    Given this I wonder whether it is right to exclude q at the source or
    to include q at the destination. In any case, it would be helpful to 
    explain your choices. But (of course) given the numbers being used to
    arrive at D using this formula including or excluding one queue time is
    not really significant.
    
    It would also be nice to note that there are n+1 nodes on your path and
    to clarify that q(i) is the delay due to queuing at node at the far end
    of the ith link.
    
    ---
    
    Not sure why section 4.3 is present in this document. It doesn't seem to
    leverage or be leveraged by anything else in the document. What is more,
    the concluding sentence ("After waiting sufficient time, packet loss can
    probably be attributed to one of these causes.") is rather vague and out
    of scope for the practice of measurement. Recall, the objective of ippm
    isto takemeasurementsandprovide reports, not to make qualatative 
    assessments of the results.
    
    ---
    
    Section 10
    
    Are there no security considerations associated with running the 
    tests over longer periods of time? What if keys roll during the 
    measurement period? Don'tlong periods offer more chance of seeing an
    attack?
  3. Stephen Farrell: Comment [2012-05-09]:
    - 3.1: what does it mean to say the 51 seconds value
    was "calculated above" when its (now, presumably)
    done in 4.1.1. (Couldn't you have arranged that 42
    seconds was the answer?)
    
    - 8.2: might have been a nice thing to include some
    reasonable representative sample sizes for some
    statistics for some measurements. Definitely too
    much to try add something with broad coverage, but
    one good, and one bad, set of example numbers 
    would be a fine addition if someone had time.
  4. Russ Housley: Comment [2012-05-09]:
      Thank you for considering the minor comments and editorial comments
      raised by Vijay Gurbani in the Gen-ART Review posted on 8-May-2012.
  5. Barry Leiba: Comment [2012-04-28]:
    Substantive suggestions; please respond to these:
    
    -- Section 5.2 --
       When both the sample mean and median are available, a comparison will
       sometimes be informative, because these two statistics are equal only
       when the delay distribution is perfectly symmetrical.
    
    I'm not a statistician, but I don't think that's true.  For example, this has a
    symmetrical distribution with 5 as the mean and median:
    
    1 1 4 4 5 6 6 9 9
    
    But this also has mean and median of 5, and its distribution is not symmetrical:
    
    1 2 3 4 5 6 6 9 9
    
    Am I missing something?
    
    ========
    Editorial suggestions.  No need to respond to these; take them or
    modify them as you please:
    
    Throughout: there's no reason to hyphenate "point of view".
    
    -- Introduction --
           in a way that facilitates determining affects on user
           applications,
    
    "effects", not "affects".
    
    -- Section 2 --
          [RFC5136] using a definition of raw capacity without the
          restrictions of data uniqueness or congestion-awareness.
    
    Don't hyphenate "congestion awareness".
    
    -- Section 3 --
    Don't hyphenate "long term" here.  (The rule is that a compound
    modifier is hyphenated, but if it's not being used as a modifier (an adjective
    or adverb), it shouldn't be hyphenated.)
    
    -- Section 3.1 --
       We have calculated a waiting time above that
       should be sufficient to differentiate between packets that are truly
       lost or have long finite delays under general measurement
       circumstances, 51 seconds.  Knowledge of specific conditions can help
       to reduce this threshold, but 51 seconds is considered to be
       manageable in practice.
    
    "above"?  Does this need to be re-worded?  Maybe "above which it", or some such?
    And 51 seconds seems oddly precise: does 50 seconds really not work, and is it
    really not appropriate to call it 55 or 60 ?  (Just asking; I have no idea of
    the answer here.)
    
       For example, the 99.9%-ile minus the minimum
    
    I suggest just spelling out "percentile" here (and in 5.2); you're not tight on
    column-inches.  If you're worried, you can compensate by removing the extraneous
    "identified as" in the net paragraph.
    
    -- Section 3.2 --
    
       The result would ideally appear in the same form as though a
       continuous measurement was conducted.
    
    Needs subjunctive mood: "had been conducted."
    
       intervals it is possible to present the results as "metric A was less
       than or equal to objective X during Y% of time.
    
    Missing closing quote.
    
       NOTE that numerical thresholds of acceptability are not set in IETF
       performance work and are explicitly excluded from the IPPM charter.
    
    Once the RFC is published, its connection with the IPPM working group is not
    obvious.  I suggest just saying, "and are out of scope for this document," or
    some such.
    
    -- Figure 2 --
    I suggest moving "where j is the hop number where the loop
    begins" out of the figure, since you already have two other "wheres" out there.
    You also don't say what "n" is, and should.  I see from below that it's the
    number of hops.  So make it, "where n is the total number of hops, j is the hop
    number where the loop begins, C is the number of times a packet circles the
    loop, and TTL is the packet's initial Time-to-Live value".
    
    -- Section 4.3 --
    In bullet 5, I would add a comma after "checking", to break up
    the length and to avoid confusion about what "and" conjoins.
    
    -- Section 5.1.2 --
    
       As further evidence of overlap, consider the Cumulative Distribution
       Function (CDF) of Delay when the value positive infinity is assigned
       to all lost packets.
    
    I suggest quoting "positive infinity" to set it off clearly.
    
       Although infinity is a familiar mathematical concept, it is somewhat
       disconcerting to see any time-related metric reported as infinity, in
       the opinion of the authors.
    
    This is consensus of the WG, not opinion of authors, right?  I suggest just
    ending the sentence at the comma.  If you need to waffle, make it "it can be
    somewhat disconcerting".
    
    -- Section 5.3 --
       the most efficient practice is to distinguish between truly lost and
       delayed packets with a sufficiently long waiting time, and to
       designate the delay of non-arriving packets as undefined.
    
    Again, it's easy to misread what the "and" conjoins.  How about this way?:
    NEW
       the most efficient practice is to distinguish between packets
       that are truly lost and those that are delayed with a sufficiently
       long waiting time, and to designate the delay of non-arriving
       packets as undefined.
    
    -- Section 7.5 --
    Last paragraph begins with a lower-case "w".
  6. Pete Resnick: Comment [2012-05-09]:
    As per your reply to Eliot Lear's Apps Directorate review, please un-2119 the
    document. I don't think it's appropriate for this document.
    
    You say "packets of type-P". Shouldn't that be "packets of type P" without the
    hyphen? Also, "type C"? With the hyphens, I'm not quite sure what you're talking
    about. Perhaps this is just unclear to someone outside the area.

draft-ietf-alto-reqs

  1. Benoit Claise: Discuss [2012-05-09]:
    Looking at Adrian's feedback on this draft, I support his DISCUSS:
        Section 3.1 needs to discuss manageability requirements for the new
        protocol(s). RFC 5706 may give you some guidance. 
    
    And as OPS A.D., I would like to carefully double-check this. 
    Hence this new
    DISCUSS position... on the top of the having some COMMENTS (the ones mentioned
    "Substantive suggestions; please adopt or respond to these:") that could
    potentially be DISCUSS
    
  2. Benoit Claise: Comment [2012-05-08]:
    Substantive suggestions; please adopt or respond to these:
    
    - Section 1. Introduction
    
       Usually, it would be difficult or even impossible for application
       entities to acquire this information by other mechanisms, e.g., using
       measurements between the peers of a P2P overlay, because of
       complexity or because it is based on network topology information,
       network operational costs, or network policies, which the respective
       network provider does not want to disclose in detail.
    
    "difficult or even impossible", "because it is based on network topology
    information, network operational costs, or network policies, which the
    respective network provider does not want to disclose in detail. "
    TWAMP type
    probes, even at the applications level, are possible, and not difficult.
    However, I believe that the real issue is the scalability: way too many peers in
    a P2P. That would imply network operational costs, sure.
    But you don't always
    need the network topology information, if you "just" want to test for the
    nearest peer.
    It would be great if you could update the text.
    
    - Section 2.3
    
       This document itemizes requirements for the following components:
       ALTO client protocols, ALTO server discovery mechanisms, host group
       descriptors, rating criteria, and host characteristics attributes.
       Furthermore, requirements regarding the overall architecture,
       especially with respect to security and privacy issues, are
       presented.
    
    I was confused by the plurals of these terms. Are you actually proposing
    multiple solutions?
    I found my answer later in the doc.:
    
       The detailed specification of an ALTO client protocol is out of the
       scope of this document.  In fact, this document does not even assume
       that there is only one single protocol specification.  However, this
       document enumerates requirements for ALTO, to be considered when
       specifying, assessing, or comparing protocols and implementations.
    
    You should move this paragraph in section 2.3, or at least put a similar
    explanation in 2.3
    
    -  REQ.  ARv14-12
    
    So basically, this is a generic requirement that ALTO is not suited for any
    real-time rating criterion. Do I get this right?
    Should you then write something
    such as: ALTO client protocol specifications MUST NOT define any rating criteria
    that vary at an order of magnitude equivalent to the RTT
    
    - 
    
       REQ.  ARv14-5: An ALTO client protocol MUST be extensible to enable
       support of other host group descriptor types in future.  An ALTO
       client protocol specification MUST define an appropriate procedure
       for adding new host group descriptor types, e.g., by establishing an
       IANA registry.
    
    Why don't you reuse an existing registry, in which you will have all the
    Information Elements already defined? I have in mind: the IPFIX I.E. in IANA
    When you will control your applications with ALTO, you will anyway want to apply
    a flow measurement to monitor your changes, and to serve as a feedback loop for
    more optimizations.
    Therefore, it would make sense to have consistent data
    models between ALTO and IPFIX.
    Proposal:
    1. New text
    
       REQ.  ARv14-5: An ALTO client protocol MUST be extensible to enable
       support of other host group descriptor types in future.  An ALTO
       client protocol specification MUST define an appropriate procedure
       for adding new host group descriptor types, e.g., by establishing or
       reusing an IANA registry.
    
    2. At the protocol design time, reusing the IPFIX ElementID
    
    -   REQ.  ARv14-28: An ALTO client protocol MUST use TCP based transport.
    
    I don't understand why you impose this? If SCTP is ever deemed to be
    beneficial...
    However, if you have a good reason to explicitly mandate TCP,
    please explain it.
    
    - REQ.  ARv14-48
    
       An ALTO
       server MUST provide adequate guidance even if the ALTO client prefers
       not to specify the desired resource (e.g., keeps the data field
       empty).
    
    I don't understand this requirement.
    Do you want to express that the ALTO
    protocol must return his full database if the data field is empty?
    Then, where
    is the guidance?
    
    ========
    Editorial suggestions.  No need to respond to these; take them or
    modify them as you please:
    
    - Section 1. Introduction
    
       The goal of
       these informed decisions is to improve performance or Quality of
       Experience in the application while reducing resource consumption in
       the underlying network infrastructure.
    QoE, please give a reference to RFC6390, where it's defined.
    
    -  Section 2.3
    
       The ALTO problem statement [RFC5693] defines a terminology (see
       Section 2 of [RFC5693] and Section 2.2 of this document), introduces
       several components.  It presents a figure that gives a high-level
       overview of protocol interaction between these components.
    Personal taste: copy the figure over. Up to you.
    
    - DHT to be expanded.
    
    - I don't see any requirements on the placement of the server.
    There are none?  Do you want to add a sentence about it?
  3. Adrian Farrel: Discuss [2012-05-08]:
    In general I support this document, but I have a number of points that
    need to be looked at before publication. A couple of them are 
    significant enough to merit points in this Discuss. The rest would not
    normally result in a Discuss, but I do feel that the volume of issues
    and the large number of Comments from other ADs suggest the need to 
    carefully revise the whole document.
    
    ---
    
    Section 3.1 needs to discuss manageability requirements for the new
    protocol(s). RFC 5706 may give you some guidance.
    
    ---
    
    REQ.  ARv14-28
    
    Two issues here:
    1. This is a very solutions-oriented requirement. Shouldn't you actually
       state the functional requirements that would lead a protocol designer
       to either re-invent many of the features of TCP or t specify the use
       of TCP?
    2. Whatever happened to SCTP?
    
    ---
    
    3.2 does not appear to support an alto client being configured with the
    location of one or more alto servers. Shouldn't you allow that? That 
    would seem to mean that it is not a requirement that every alto client 
    be able to use discovery.
    
    But, in any case, REQ.  ARv14-35 seems to be about implementation, not
    about protocol design.
    
  4. Adrian Farrel: Comment [2012-05-08]:
    Although not part of the Discuss, I would strongly recommend that you
    work through these Comments before publication.
    
    ---
    
    I think you need to be really careful in your use of the word
    "resource". It is very clear from the first sentence of the Abstract
    what you mean by resource andthis is important in interpretation of the
    whole problem space. Unfortunately, the last sentence of the first 
    paragraph of the Abstract muddies the waters by also using the word
    with less precision.
    
    The problem surfaces in the body of the text as well.
    
    I think you might do well to talk about "application resources" and
    "network infrastructure resources" and include clear definitions early
    in the document (probably Section 1; i.e., before the terminology
    section).
    
    ---
    
    Section 2.3
    
       The ALTO problem statement [RFC5693] defines a terminology (see
       Section 2 of [RFC5693] and Section 2.2 of this document), introduces
       several components. 
    
    Something wrong. problem with parentheses?
    
    ---
    
    REQ.  ARv14-1
    
    A little surprised that the requirement is only that the client and 
    server must each implement *an* alto client protocol. Wouldn't it be
    helpful if they implemented the same protocol? Maybe a forward pointer
    to section 3.2?
    
    ---
    
    REQ.  AR14-6 and 14-7
    
    I don't understand how all host group descriptors can easily be mapped
    to one or a set of IP addresses. You have cited as an example in the
    terminology section's definition of host group descriptor that such a 
    description may be an AS. While it is nominally possible to map an AS
    to a set of IP addresses, it is not necessarily very clean.
    
    However, I read the definition as meaning that there are some additional
    qualifiers to a host group that may be useful. Thus a host group may be
    described by an IP prefix *and* an AS to give additional information 
    that is more helpful than just the IP prefix.
    
    ---
    
    REQ.  ARv14-20
    
    Should this requirement make clear that separate instances of alto 
    servers are not required to generate the same results? Or, conversely,
    if you want to surprise me by saying this is a requirement, you will
    need to state it in the document.
    
    ---
    
    REQ.  ARv14-24
    
    I am uneasy about the mother-knows-best nature of the control of re-use
    in this requirement. Why is it not possible to state the issues with the
    supplied response data and allow the client to decide whether it wants
    to re-use the response or not? In practice, the fact that a response is
    marked "no re-use should occur" is not compelling to a client. But 
    marking the response "this data is only valid for the requesting client
    for 38 seconds" is likely to suggest to the client that redistribution
    is pointless.
    
    ---
    
    REQ.  ARv14-25
    
    Can the alto server be behind a NAT?                                     
    
    ---
    
    Section 3.1.6 is all about leveraging "mechanisms provided by underlying
    protocol layers". Surely, that is just one of the congestion indicators
    at an alto server. What about queues at the message layer? What about
    CPU load?
    
    In fact, this section could be easily rewritten to say that:
    
    The protocol MUST allow a server that experiences or is aware of 
    congestion in the network, in processing of alto messages, or in its
    overall processing load to report any of the following advice through an
    alto response:
    ...
    
    ---
    
    Shouldn't section 3.2 also require disclosure of server capabilities?
    And isn't there a meta-alto point here that the discovery should use
    exactly the same Rating Criteria and Host Characteristic Attributes as
    defined in the altoclient protocol?
    
    ---
    
    Section 3.3
    
    Given the security requirements described here, shouldn't there also be
    security for the discovery mechanism?
  5. Stephen Farrell: Discuss [2012-05-09]:
    
    I'm a bit confused by what might be a conflict
    between sections 3.3 and 5.2. The former says that
    nothing is mandatory-to-use, but the latter says
    that "neither the ALTO server nor a third party
    using or misusing the ALTO service should be able to
    infer the application behavior, e.g., who is
    exchanging which files with whom using a P2P file
    sharing application." I can't see how the latter can
    be guaranteed if the former is true. (And as a
    side-issue, maybe s/should/SHOULD/ above.)
    
  6. Stephen Farrell: Comment [2012-05-09]:
    Its surprising that most of the text in section 5 is
    about protecting the operator's interests. If that's
    just because the user's interests are taken as
    given, that might not be a good plan, since people
    might point back at this document and draw some
    conclusions from the relative amounts of text.
  7. Brian Haberman: Comment [2012-05-02]:
    I agree with Barry that some of the requirements should be re-worded.
    Otherwise, I have no issues with publishing this document.
  8. Barry Leiba: Comment [2012-04-28]:
    Substantive suggestions; please adopt or respond to these:
    
       REQ.  ARv14-9: An ALTO client protocol specification MUST define
       mechanisms, which can be used by the ALTO client to indicate
    
    This looks like it was meant to be restrictive, not non-restrictive (as it's
    written).  Need to remove the comma and preferably change "which" to "that".
     This applies to Req 16 also.  This really is an important distinction in
    English, so please fix this.  (You got it right in Req 8.)
    
    NEW
       REQ.  ARv14-9: An ALTO client protocol specification MUST define
       mechanisms that can be used by the ALTO client to indicate
    
    -- Req 13 --
    This isn't a requirement on the client protocol, but one on the
    client implementations.  That's a different thing.  I don't object to those
    being recorded in this document also, but they should be in a separate section,
    and not intermixed with protocol requirements.  (The way Req 3 is written, it's
    that way as well, though it might best be rephrased to clearly be a requirement
    on the protocol.)
    
    -- Req 28 --
    Why is this a requirement?  It may well be that the protocol(s)
    that get specified use TCP, but what's the reason to *forbid* the development of
    one that uses, say, SCTP?
    
    ========
    Editorial suggestions.  No need to respond to these; take them or
    modify them as you please:
    
    -- Section 2.2 --
    OLD
          Some rating criteria, such as "low
          topological distance", need to include a reference point, i. e.,
          "low topological distance from a given resource consumer".
    
    I presume that should be "e.g.", not "i.e.".  That is, there are other
    possibilities.  There's another instance of this as well.  I actually recommend
    forgoing the Latin abbreviations, and just using "that is" instead of "i.e." and
    "for example" instead of "e.g.". It avoids this confusion.
    
    -- requirements --
    
    General: some of the requirements seem a bit silly... Req 1 is especially so,
    and 21 seems like another.  But I suppose it's harmless to put some obvious
    things in as requirements, so I don't object.  Req 4 is another example...not
    really "silly", but more in the line of protocol *specification* than
    requirements.  There are a few others of these, too (24 is doing a lot of
    protocol specification while it's stating its requirement).
    
    -- Req 12 --
    What is the purpose of the indentation of the second paragraph?  It
    looks like a blockquote, but there's no citation, so I suspect there's another
    purpose... but the purpose isn't clear.
    
    -- Req 29, 30, 31 --
    I think these would be clearer if they were in one
    requirement (and the extraneous implementation info in the second paragraph of
    29 were removed).  Something like this:
    NEW
       REQ. ARv14-29: An ALTO client
    protocol specification MUST
       specify mechanisms, or detail how to leverage
    appropriate
       mechanisms provided by underlying protocol layers, that can
       be
    used by an ALTO server to inform ALTO clients about an
       impending or occurring
    overload situation, and provide all of the
       following options to the server:
    - request the client to throttle its query rate
       - redirect the client to
    another ALTO server
       - terminate the conversation with the client
    
    -- Req 32, 33, 34 --
    Same comment as for 29-31.  And the note after 33 is also a
    protocol specification issue, not a requirement on the protocol.
    
    -- Section 4 --
    This seems unnecessary.  Subsequent documents may always have
    IANA actions.  Please just say "This document has no IANA actions, and the RFC
    Editor should remove this section prior to publication."
    
    -- Section 5 --
    Just a comment that this section looks very well thought out.
     Thanks for putting the effort into this.
  9. Pete Resnick: Discuss [2012-05-10]:
    1. In his Apps Directorate review <http://www.ietf.org/mail-archive/web/apps-
    discuss/current/msg03337.html>, Ted Hardie expressed concerns that some privacy
    issues are not properly addressed by this document. I agree, and these issues
    were not addressed in the latest revisions to the document. As he notes in
    particular:
    
    - I do not equate "disclosure of application behavior" to "disclosure of privacy
    sensitive user data", and I do not think the document is clear enough on this
    point.
    
    - Disclosure of aggregated data about queries is not addressed.
    
    2. I am not clear on the desirability of publishing this document at all. As is
    apparent from the discussion of Ted's review, there are places where the
    requirements document did not keep up with the actual completed protocol spec.
    (See discussion of ARv11-23 and ARv11-24.) That's fine, but it does make one
    question why this is being published once the spec is finished. Is there an
    expectation that future specs are going to have to rely on this document? As
    Enrico's response to Ted's review makes clear:
    
       All in all, the document has been extremely useful, basically
       replacing the issue tracker tool the WG -- despite trying quite hard
       -- has never found a way to use effectively. The document has proved
       to be extremely useful in archival sense of recording and tracking
       the evolution of the ALTO protocol as it progressed in the WG and as
       new capabilities, actions and use cases were raised.
    
    If the issue tracker had been used instead of this document, there would be
    nothing to publish, and AFAICT, that would have been fine. Instead of fighting
    with this document to make it agree with the spec and cover cases that have been
    overtaken by events, why not drop it?
    
    I'm especially curious about the note in the shepherd report:
    
       (1.e) How solid is the WG consensus behind this document? Does it
       represent the strong concurrence of a few individuals, with others
       being silent, or does the WG as a whole understand and agree with it?
    
       Strong consensus for publishing.
    
    Was there strong consensus for publishing because people thought this document
    would be of importance for people to read in the future in order to base work on
    it, or did people simply think that, "We've put so much work into this, we think
    it should be published."? I don't see a need to publish, and I'd like to hear
    some justification to do so.
    
  10. Pete Resnick: Comment [2012-05-09]:
    Please review Ted's other minor comments in his Apps Directorate review
    <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03337.html> and
    address as appropriate.

draft-ietf-mpls-tp-oam-analysis

  1. Benoit Claise: Comment [2012-05-09]:
    - Thanks for this document, and specifically for the tables in section 4, as
    it's difficult to find his way in a world full of MPLS OAM RFCs (requirements,
    framework, Fault specific, Packet Loss and Delay, you name it ). Along the same
    lines, I welcome http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-06,
    which has got a broader scope.
    
    - 
    
       o  The OAM toolset developed for MPLS based transport networks needs
          to be fully inter-operable with existing MPLS OAM tools as
          documented in [RFC 5860].
    
    Are you referring to http://tools.ietf.org/html/rfc5860#section-2.1.6
    
       When MPLS-TP is run with IP routing and forwarding capabilities, it
       MUST be possible to operate any of the existing IP/MPLS and PW OAM
       protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD
       [14]).
    
    The document would benefit from clearly identifying what you mean.
    
    This is even more confusing because you mention just below:
       The MPLS-TP OAM toolset is based on the following existing tools:
    
       o  LSP-Ping as defined in [RFC 4379].
    
       o  Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880]
          and refined in [RFC 5884].
    
       o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has
          been used for functionality guidelines for the performance
          measurement tools that were not previously supported in MPLS.
    
       It should be noted that certain extensions and adjustments have been
       specified relative to the existing MPLS tools, in order to conform to
       the transport environment and the requirements of MPLS-TP.  However,
       compatibility with the existing tools has been maintained.
    
    "compatibility with the existing tools has been maintained" I guess that you
    meant the list above: LSP-Ping, BFD, Y.1731. So what about the delta from my
    previous point: VCCV, and VCCV-BFD?
  2. Adrian Farrel: Comment [2012-04-23]:
    Muly Ilan raised the following points on the MPLS list. They should
    be looked at:
    
    > 1. Table 2, second row - only Lock Instruct is G-Ach based. Loopback
    >    is a management command.
    >
    > 2. Table 2, second row - LSP Ping is not related to Lock Instruct or
    >    loopback command.
    >
    > 3. Table 2, third row - Lock Instruct is not indicated by a flag in
    >    AIS message and is not discussed in RFC6427.
    >
    > 4. Section 5.2, third paragraph - need rewriting, per RFC6435
    >    there's no loopback request message nor loopback response message.
  3. Stephen Farrell: Comment [2012-05-08]:
    (Oops wrong button, I've no objection really:-)
    
    - draft-ietf-mpls-tp-security-framework-02, May 2011 was
    updated by a -03 in October 2011.
    
    - weird references, the spaces muck up tools: 
    [MPLS TP ITU Idents]
    [MPLS-TP Security Frwk]
    
    - s/MPSL-TP/MPLS-TP/ maybe?
  4. Barry Leiba: Comment [2012-04-29]:
    -- Section 7 --
       In addition to implement security protocol, tools, and mechanisms,
       following strict operation security procedures is very important,
       especially MPSL-TP static provisioning processes involve operator
       direct interactions with NMS and devices, its critical to prevent
       human errors and malicious attacks.
    
    This paragraph needs to be turned into more understandable English.  I'd offer,
    but I don't understand what it's trying to say well enough to do it (hence, this
    comment).  I suggest that it needs to be two or three sentences, rather than
    just one, and the grammar needs to be corrected so it's clear what it's saying.
    [I note that the rest of the document is fine to read; it's only this section
    that has any notable problem.]
    
    The next paragraph also has a couple of minor grammatical errors, but it's
    understandable:
    OLD
       Since MPLS-TP OAM uses G-ACh, the security risks and
    mitigation
       described in [RFC 5085] apply here.  In short, the G-ACh could be
    intercepted, or false G-ACh packets could be inserted.  DoS attack
       could
    happen by flooding G-ACh messages to peer devices.  To mitigate
       this type of
    attacks, throttling mechanisms can be used.  For more
       details, please see
    [RFC 5085].
    NEW
       Since MPLS-TP OAM uses G-ACh, the security risks and
    mitigation
       described in [RFC 5085] apply here.  In short, the G-ACh could be
    intercepted, or false G-ACh packets could be inserted.  DoS attacks
       can be
    mounted by flooding G-ACh messages to peer devices.  To
       mitigate this type of
    attack, throttling mechanisms can be used.
       For more details, please see [RFC
    5085].
  5. Martin Stiemerling: Comment [2012-05-07]:
    Section 8., paragraph 3:
    
    >    Thanks to Rui Costa for his review and comments which helped improve
    >    this doecument.
    
      s/doecument/document/

draft-ietf-avtext-splicing-for-rtp

  1. Stewart Bryant: Discuss [2012-05-10]:
    Given that advertisement insertion in IPTV seems to be a deployed technology,
    and given that there are television SDOs working on IPTV, I would like to
    understand what input those SDOs and vendors had into this requirements set.
    
    Although this is a requirements specification, it seems to go into
    implementation detail, for example section 4.1
    
    There needs to be considerably more thought given to the security model to
    protect both the content provider and the viewer.
    
    Given the large number of comments and discusses, I request that a future
    revision of this document is brought back to the IESG for review.
    
  2. Benoit Claise: Comment [2012-05-10]:
    Much has been said already with the multiple DISCUSS feedback on this draft. So,
    no need to repeat the information: I'll trust the other ADs will take care of
    this one.
  3. Wesley Eddy: Comment [2012-05-09]:
    I support Stephen's DISCUSS points.
    
    REQ-3 seems broad and unspecific given the range of RTP/RTCP extensions.  REQ-4
    is vague on what it really means technically, and REQ-5 is also vague in regards
    to what the performance consists of and lacks rationale for why it needs to be
    relayed back.  REQ-6 seems misformatted.
    
    As written, I do not think this document is useful to be permanently published
    as an RFC.  It starts with the assumption that splicing is necessary for some
    use case and doesn't consider whether other approaches can meet the same actual
    requirements (of the use case, NOT of the splicing solution chosen).  It
    recommends a solution without clearly comparing any alternatives.
  4. Adrian Farrel: Comment [2012-05-10]:
    In view of the large number of Discuss and Comment issues raised, I am not going
    to spend time reviewing this version of the document. If the document returns to
    a future telechat I will review it then.
  5. Stephen Farrell: Discuss [2012-05-09]:
    - REQ-4: What exactly does it mean to say that the
    splicer must be trusted by the receiver? I would
    have guessed that most receivers would not know of
    the splicer's existence. The reason this is a
    discuss is that I am worried that the consequences
    of treating a "transparent proxy" (as they're called
    in HTTP) as if it were "trusted" could be damaging
    to the Internet.
    
    - REQ-4 and REQ-6 seem to me to be in conflict.  How
    can a receiver "trust" a splicer and yet be
    prevented from knowing what the splicer has done? 
    
    - From the above, it seems to me that if there are
    any security requirements here then the receiver
    needs to have a direct relationship with the
    splicer, as does the sender, so that e.g. any
    encrypted traffic is decrypted at the splicer, and
    then re-encrypted.
    
    - Is the text in the 1st two paragraphs of 4.2
    saying that we are encouraging hosts on the Internet
    to fool one another and engineering our protocols to
    make it harder for some of them to figure out they
    are being fooled?  That doesn't seem like a good
    goal to me, without a lot more justification.
    
    - Changes to RTCP reports and loss values as
    suggested here would also seem to preclude any real
    e2e security. I just don't get why that is ok.
    
    - If so-called "user invisibility" is required (and
    there is no REQ-X for that) and it has the
    consequence of creating loops then that ought be
    described, and it isn't.
    
    - If "invisible" splicing were really possible, then
    how could any supposedly "secure" RTP session ever
    be trusted by a receiver?
    
  6. Stephen Farrell: Comment [2012-05-09]:
    section 1:
    - s/into internet/into the Internet/
    - s/changes to transport layer/changes to the
       transport layer/
    - s/requirements of RTP splicing/requirements
       for RTP splicing/
    
    - REQ-1, what environments other than unicast or
    multicast might exist? If this isn't a tautology
    then I don't know what's meant.
    
    - REQ-3, I'm not clear what backward compatible
    means here - the splicer seems to be talking
    RTP/RTCP for both main and current content in Figure
    1, so what element of backward compatibility is
    meant here?
    
    - Is the reference to SCTE30 meant to  be the 2001
    version? I only found the 2009 version on scte.org,
    but didn't hunt much. For SCTE35 2007 is referenced,
    but there's a 2011. What's up there?  Stable URLs
    for those and the ISMA document would be good.
  7. Barry Leiba: Comment [2012-04-30]:
    Substantive but non-blocking comments; please adopt or respond to these:
    
    -- General --
    I see from the mailing list discussion that there had been some
    consideration of using an RTP translator, rather than an RTP mixer.  It appears
    that mixer was chosen more or less by default -- there was a concrete proposal
    for it, and none for the other.  Given that, it might be nice to have a few
    words (maybe a small section at the end, maybe an appendix, something like that)
    about the possibility of using an RTP translator, and why using a mixer is
    better.  If the WG considered the issue, others are likely to as well.  But feel
    free to respond, "Yes, it might, but that is not this document."  :-)
    
    -- Abstract --
    You talk about proposing the use of "an existing RTP level
    middlebox", and you do know what that middlebox is.  I suggest saying so.  Maybe
    like this:
    NEW
       and analyze whether an RTP mixer (an
       existing RTP level
    middlebox) can meet these requirements.  Finally,
       we provide concrete
    guidelines for how the RTP mixer can work to
       handle RTP splicing.
    
    You might also mention this in the last paragraph of the Introduction.
    
    -- Section 4 --
    
    Where is an "RTP mixer" defined?  Should there be a reference?  I don't see a
    definition in RFC 3550 -- the term is used there, but not defined.
    
    I also suggest expanding SSRC and CSRC on first use.
    
    -- Section 4.1 --
    
    I really dislike the odd "pseudo-code" format to illustrate the process.  It's
    already more prose than pseudo-code, and I strongly urge you to re-cast it as
    normal text.
    
    -- Security Considerations --
    The first paragraph is a little fluffy about what
    the issue is.  What makes "regular transport security mechanisms" different
    here... that is, what's the *real* point?  Is it that end-to-end encryption
    makes it impossible for the middlebox to play with the stream, but hop-by-hop
    encryption allows it?  I'd like to see this be clearer about what the conditions
    are that makes this feasible vs impossible, and then whether there are any
    security issues involved with allowing a middlebox to replace parts of the
    stream.  (It's possible that there are none, when the trust model in the second
    paragraph is correct.)
    
    ========
    Editorial suggestions.  No need to respond to these; take them or
    modify them as you please:
    
    -- General --
    There are numerous English-language issues with the document, too
    many to detail with OLD/NEW suggestions.  The document would benefit from a pass
    by a native English speaker to fix the grammar, punctuation, and such, and I
    strongly suggest such an edit.  That said, the document is readable as it is,
    and these are edits the RFC Editor will make if we don't do it before.  (Note
    that this is a complaint against the WG, not against the editor.  WGs should be
    addressing this sort of issue in their review, and should appoint a co-editor in
    cases where the primary editor needs help getting the English right.)
    
    -- Section 4.4 --
    One language thing that I think really does have to be fixed now, for clarity:
    OLD
       In practice, during splicing, the real reason to cause congestion
       usually is the different characteristic of substitutive RTP stream
       (more dynamic content or higher encoding bitrate) with main RTP
       stream, and that stream transcoding or thinning on mixer is very
       inefficient and difficult operation.
    
    NEW
       In practice, the usual real causes of congestion during splicing
       are the differences in characteristics between the substitutive RTP
       stream and the main RTP stream -- when the former has more dynamic
       content or a higher encoding bitrate -- and that stream transcoding
       or thinning on the mixer is very inefficient and difficult.
    
    -- IANA Considerations --
    
    I suggest adding a sentence asking the RFC Editor to remove this section before
    publication, which is usual practice for empty IANA Considerations sections.
  8. Pete Resnick: Discuss [2012-05-09]:
    This document is nowhere near ready for the IESG. The large number of things
    that are so poorly edited as to be unclear what the meaning is (i.e., not just
    grammatical mistakes which we see in all documents) indicates to me that it did
    not have sufficient review.
    
    I don't think REQ-2 is an actionable protocol requirement. Given section 4.3, it
    appears that what you mean by REQ-2 is something like, "Make the sound and
    picture change be smooth", in which case it's not a protocol requirement at all.
    Making the media transition be smooth involves a great deal of knowledge about
    the nature of the media being sent. You may need to do fading, or some other
    thing to make sure that the boundary between the main media and the substitutive
    media is seamless. There's nothing to be done in protocol for this; you have to
    know something about the media itself. And it is hard to reconcile this with the
    statement in section 4 which says, "splicing is not a very complicated
    processing". Presumably REQ-2 is not really about the buffering, which should
    not be an issue at all because you are presumed to already know when splicing
    begins and ends:
    
       The methods how Splicer learns when to start and end the splicing is
       out of scope for this document.
    
    So you should already know where you're going to start inserting your data into
    the stream.
    
    REQ-6 is not a requirement at all. First, as Stephen says, it conflicts with
    REQ-4. But even beyond that, the body of the requirement is basically saying,
    "Do it if it is convenient." The document does no analysis as to the
    effectiveness of the "trade-off" invisibility (simply maintaining RTP header
    params) to see if it's even worth doing so. I don't see what an implementer
    reading REQ-6 would do.
    
  9. Pete Resnick: Comment [2012-05-09]:
    4.1 - I don't see what the first paragraph is telling anyone. Presumably if you
    are a splicer, you know that you will need data to insert into the stream and
    that it will be coming from somewhere. What is the purpose of the first
    paragraph?
    
    Paragraph 2 starts, "Even if splicing does not begin". Do you simply mean,
    "Before splicing begins"? Otherwise, I don't understand what this sentence is
    saying. Also, unlike the rest of the paragraphs, it does not talk about
    "encapsulating". I assume it should, yes?
    
    Paragraph 3 only mentions a substitutive RTP stream and not local media.
    
    I agree with Barry that the pseudo code is useless, if not just confusing, and
    should be removed. The prior text should include all of the information that
    would have been in the pseudocode.
    
       Note that, the substitutive content should be outputted in the range
       of splicing duration.
    
    I do not understand the above sentence.
    
    4.3 -
    
       If the time slot for substitutive RTP stream mismatches (shorter or
       longer than) the duration of the reserved main RTP stream for
       replacing, the media clipping may occur at the splicing point which
       usually is the joint between two independently decodable frames.
    
    I understood everything up to the word "which", but I don't understand the
    importance of what comes after that. But even before that, I'm not clear on
    whether you mean "clipping" or simply "truncation". The last paragraph of 4.3
    seems to talk about true clipping, but the rest of this seems to be about
    extending media that does not fill a time slot or truncating media which
    overfills a slot and how to make those transitions look smooth. I wouldn't call
    all of these "clipping".
  10. Robert Sparks: Discuss [2012-05-08]:
    (Clearing up some minor typos to make these easier to read) 
    
    It's not clear what a mixer implementer should be doing with the advice in the
    last full paragraph on page 12. How is that implementer supposed to apply
    something like RFC5348 or RFC5762? Is this feedback running between the mixer
    and the receiver, the mixer and the source, or something else? In any case, it
    should be made explicit that this isn't asking the mixer to begin transcoding.
    
    The pseudo code blocks each say "the timestamp of the current RTP packet
    increments linearly" and that is unclear. Is this trying to say that the mapping
    from the timestamp in the input packet to the mixer and the output packet be
    linear?
    
    The implementations considerations section says there is a potential issue with
    loop detection, but doesn't actually describe the issue, or how satisfying the
    user invisibility requirement makes it more likely to occur.
    
    The document should be explicit about the expected trust model if SRTP is used.
    I believe it is currently assuming that media from either source would be
    decrypted at the mixer and re-encrypted towards the receiver(s). The first
    paragraph in section 6 could be read to imply that the mixer is just forwarding
    SRTP packets.
    
  11. Robert Sparks: Comment [2012-05-08]:
    When considering the clarification for the first point above, consider making
    the first two paragraphs of section 4.2 clearer as well.
    
    CSRC is typo'd as CRSC in a few places.
  12. Martin Stiemerling: Discuss [2012-05-07]:
    Section 4.1., paragraph 3:
    
    >    When splicing begins, mixer chooses the substitutive RTP stream as
    >    input stream at splicing in point, and extracts the payload data
    >    (i.e., substitutive content).  After that, mixer encapsulates
    >    substitutive content instead of main content as the payload of the
    >    current media stream, and then outputs the current media stream to
    >    receiver.  Moreover, mixer may insert the SSRC of substitutive RTP
    >    stream into CSRC list in the current media stream.
    
      What happens if the payload of the received substitutive RTP stream
      is larger than the maximum RTP payload of the outgoing RTP stream?
    
  13. Martin Stiemerling: Comment [2012-05-07]:
      General comment: This document is in need of a lot of language
      improvements, e.g., replacing 'Splicer' with 'the Splicer' all over
      to improve readability. It seems that almost no arcticles have been
      used. This makes reading the text very, very hard, at least for me
      as non-native speaker.
    
    Section 1., paragraph 4:
    
    >    So far [SCTE30] and [SCTE35] have standardized MPEG2-TS splicing
    >    running over cable.  The introduction of multimedia splicing into
    >    internet requires changes to transport layer, but to date there is no
    >    guideline for how to handle content splicing for RTP sessions
    >    [RFC3550].
    
      Curious to see what the required changes to the transport layer are?!
      I have
    not found any change required to the transport layer, e.g., TCP, UDP, DCCP, etc.
    
    Section 3., paragraph 4:
    
    >    When RTP splicing begins, Splicer stops delivering the main content,
    >    instead delivering the substitutive content to RTP receiver for a
    >    period of time, and then resumes the main content when splicing ends.
    >    The methods how Splicer learns when to start and end the splicing is
    >    out of scope for this document.  The RTP splicing may happen more
    >    than once in case that substitutive content will be dispersedly
    >    inserted in multiple time slots during the lifetime of the main RTP
    >    stream.
    
      Trying to improve the readability by suggesting this:
     OLD:
     Splicer stops delivering the main content,
     NEW:
     the Splicer stops delivering the main content to the RTP receiver,
    
    Section 3., paragraph 7:
    
    >       Splicer must operate in either unicast or multicast session
    >       environment.
    
      Shouldn't this better read
     "The Splicer must support either unicast delivery
    or multicast delivery."
     or should the Splicer be able to support both modes at
    the same time and not just one at a time. If so, the sentence should read
     "The
    Splicer must support unicast delivery or multicast delivery."
    
    Section 3., paragraph 11:
    
    >       Splicer must be backward compatible with RTP/RTCP protocols, and
    >       its associated profiles and extensions to those protocols.  For
    >       example, Splicer must be robust to packet loss, network congestion
    >       etc.
    
      I do not see what the relationship between "backward compatible
      with RTP/RTCP protocols " and robust to packet loss, etc is.
    
    Section 3., paragraph 15:
    
    >       Splicer should allow the media source to learn the performance of
    >       the downstream receiver when its content is being passed to RTP
    >       receiver.
    
      What does this mean on the protocol level?  Is this referring to
      support RTCP relaying, an out-of-band mechanism, or what?
    
    Section 4.1., paragraph 13:
    
    >       the CSRC list of the current RTP may include SSRC of main RTP
    >       stream;
    >    }
    >    Splicing may occur more than one time during the lifetime of main RTP
    >    stream, this means mixer needs to output main content and
    >    substitutive content in turn with its own SSRC identifier.  From
    >    receiver point of view, the only source of the current stream is
    >    mixer wherever the content comes from.
    
      The last sentence is a potentially misleading, as the receiver can
      identify the last mixer wherever the content comes from.
    
    Section 4.2., paragraph 2:
    
    >    According to the description in section 7.3 of [RFC3550], mixer
    >    divides RTCP flow between media source and receiver into two separate
    >    RTCP loops, media source probably has no idea about the situation on
    >    receiver.  Hence, mixer can use some mechanisms, allowing media
    >    source to at least some degree to have some knowledge of the
    >    situation on receiver when its content is being passed to receiver.
    
      The last sentence is not making any point, other saying that there
      is something which isn't specified here. Not sure if this sentence
      is needed and if yes, it should reworded to make clear that there
      are mechanisms and reference to those.
    
    Section 4.2., paragraph 3:
    
    >    Because splicing is a processing that mixer selects one media stream
    >    from multiple streams but neither mixing nor transcoding them, upon
    >    receiving an RTCP receiver report from downstream receiver, mixer can
    >    forward it to original media source with its SSRC identifier intact
    >    (i.e., the SSRC of downstream receiver).  Given that the number of
    
      I'm lost by this sentence, as I have difficulties in parsing it. It
      is too long and needs some re-wording.
    
    Section 4.2., paragraph 8:
    
    >    If the substitutive content comes from local media file storage (
    >    i.e., mixer can be regarded as the substitutive media source), the
    >    reception reports received from downstream relate to the substitutive
    >    content should be terminated on mixer without any further processing.
    
      the reports **must** be terminated, instead of using **should*, on the mixer,
      if the content is served from a local file.
    
    Section 4.4., paragraph 1:
    
    >    Provided that the substitutive content has somewhat different
    >    characteristics to the main content it replaces (e.g., the more
    >    dynamic content, the higher bandwidth occupation), or substitutive
    >    content may be encoded with different codec and has different
    >    encoding bitrate, some challenge raise to network capacity and
    >    receiver buffer size.  A more dynamic content or a higher encoding
    >    bitrate stream might overload the network and possibly exceed the
    >    receiver's media consumption rate, which might flood receiver's
    >    buffer and eventually result in a buffer overflow.  Either network
    >    overload or buffer overflow would induce network congestion and
    >    congestion-caused packet loss.
    
      overload is quite a generic term. Since you are pointing at causing
      congestion, it might be good to say that congestion can occur in
      the network due to sending the content.
    
    Section 4.4., paragraph 1:
    
    >    Upon detection of above three types of RTCP reports during splicing,
    >    mixer will treat them with three different manners as following:
    
      This sentence is really hard to parse. Do you mean to say:
    
    Section 4.4
    
    >    Once mixer learns that congestion is being experienced on its
    >    downstream link by means of above three detection mechanisms, it
    >    should adapt the bitrate of output stream in response to network
    >    congestion.  The bitrate adaptation may be determined by a TCP-
    >    friendly bitrate adaptation algorithm specified in [RFC5348], or by a
    >    DCCP congestion control algorithms defined in [RFC5762].
    
      adapting the bitrate depending on the outcome of TCP-friendly rate
      control or DCCP congestion control might not be an option, if the
      content requires a certain bitrate. It might be worth mentioning it
      here that congestion may result in stopping the delivery completely.
    
    Section 6., paragraph 1:
    
    >    If any payload internal security mechanisms (e.g., ISMACryp
    >
    [ISMACryp]) are used, only media source and RTP receiver can learn
    >    the
    security keying material generated by such internal security
    >    mechanism, any
    middlebox (e.g., mixer) between media source and RTP
    >    receiver can't get
    such keying material.  Only when regular transport
    >    security mechanisms
    (e.g., SRTP, IPSec, etc) are used, mixer will
    >    process the packets passing
    through it.
     COMMENT:A nit: IPSec is not a transport security mechanism.
     To be
    even more nitty: IPSec delivery might also block a mixer if the security
    association is set up between the media source and the RTP receiver. This is
    similar to payload internal security mechanism.
  14. Sean Turner: Comment [2012-05-10]:
    I support the discuss positions from the other ADs.

draft-ietf-avtext-rams-scenarios

  1. Stephen Farrell: Comment [2012-05-09]:
    I agree with the secdir review and Barry's comment
    about the security considerations and believe this
    is being handled already.
  2. Russ Housley: Comment [2012-05-06]:
      Please consider the editorial issues raise in the Gen-ART Review by
      Vijay Gurbani on 27-Apr-2012.  The review can be found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07402.html
  3. Barry Leiba: Comment [2012-04-29]:
    Substantive comments; please adopt or respond to these:
    
    This seems to be a well written document.
    
    Security Considerations:
    Might it not be better to say something like this?:
    "Because this document describes deployment scenarios for RAMS, all security
    considerations are specified in the RAMS specifiction [RFC6285]."
    
    ========
    Editorial suggestions.  No need to respond to these; take them or
    modify them as you please:
    
    IANA Considerations:
    You might add an RFC Editor note to remove this section
    prior to publication, which is the normal practice for "empty" IANA
    Considerations sections.
  4. Martin Stiemerling: Comment [2012-05-07]:
    A good document and I have one substantial comment to be addressed:
    
    It is required to add a reference to RFC 6285 about the discussion of RAMS
    potentially causing congestion. The place to add this would be in the beginning
    of Section 5.  "FEC during RAMS and Bandwidth Issues".
    Otherwise, Section 5 is
    sort of incomplete, as it suggests that RTP sender and receiver have alway full
    knowledge about the state of the network path between both. RFC 6285 is
    documenting the challenges nicely.

draft-ietf-mboned-mcaddrdoc

  1. Stewart Bryant: Comment [2012-05-10]:
    "The use of specific multicast addresses for documentation purposes has no
    impact on security."
    
    Actually isn't it a security improvement?
  2. Benoit Claise: Comment [2012-05-07]:
    I would propose one text improvement:
    OLD:
    
      GLOP [RFC3180] is a method for deriving IPv4 multicast group
       addresses from 16 bit AS numbers.
    
    NEW:
       GLOP [RFC3180] can be used by anyone who owns a registered AS number
       to derive 256 global multicast addresses, by mapping the AS number in the
       middle 16 bits of the IPv4 multicast address 233/8.
  3. Adrian Farrel: Discuss [2012-05-03]:
    The authors have agreed to update the IANA section following the Routing
    Directorate review by Geoff Huston and email exchanges with IANA. This Discuss
    holds the document until that update has been done.
    
  4. Brian Haberman: Discuss [2012-04-30]:
    I support the publication of this document, but I think there are a few things
    that should be DISCUSSed.
    
    1. Should IANA reserve the multicast addresses that are constructed from the
    unicast prefixes allocated for documentation use?  For example, should
    FF3X:20:2001:DB8::/64 be reserved?
    
    2. Was there any consideration given for how permanent IPv6 multicast addresses
    could be represented in documentation (i.e., flag T=0)?
    
  5. Brian Haberman: Comment [2012-04-30]:
    1. This draft states that for IPv4, 233.252.0.0/24 is reserved for
    documentation.  The IANA registry lists that range as being assigned to MCAST-
    TEST-NET.  Should this description be updated to reflect its new use as a
    documentation range?
    
    2. It may be useful for the draft to mention why the IPv6 address request to
    IANA is for a /96.  Referencing RFC 3307 and its method of allocating the lowest
    32-bits of multicast addresses would be sufficient.
  6. Pete Resnick: Comment [2012-05-09]:
    I won't object given that RFC5737 and RFC3849 were both Informational, but
    shouldn't this kind of thing be BCP?
    
    I agree that the IANA Considerations section needs serious rewriting. It needs
    to include the list of reserved addresses.

draft-sprecher-mpls-tp-oam-considerations

  1. Benoit Claise: Comment [2012-05-09]:
    Thanks for the document.
    
    Three editorial points:
    - Transport profile -> Transport Profile
    
    - "It is possible to argue that using MPLS for Transport is only a
       stepping stone in the middle of a longer transition."
    Transport -> transport or Transport Profile?
    
    -  "As we shall demonstrate, ..."
    The RFC editor gave me in the past the advice
    to remove "we", "us", "our" from the future RFCs.
  2. Stephen Farrell: Comment [2012-05-08]:
    I fully support the conclusion here and the argument
    varies from compelling at best to good enough at
    worst.
    
    typos: 
    
    s/documentationin/document in/?
    s/viably/viability/
    s/a E1 only/an E1 only/
  3. Russ Housley: Comment [2012-05-06]:
      Section 7 should be removed before publication as an RFC.
    
      The Gen-ART Review by Brian Carpenter reported one editorial problem.
      There is duplicated text in section 1.2:
    
       ...
       be managed using tools with similar look and feel.  The requirements
       specifications [RFC5654] and [RFC5860] specifications [RFC5654] and
       [RFC5860] capture the essential issues that must be resolved to allow
       ...
  4. Barry Leiba: Comment [2012-05-02]:
    Excellently written, clear document.
    
    Just a few minor editorial things; no need to reply to them:
    
    -- Section 3.4 --
    OLD
       In an isolated system this may be the
       case, however when, as is usually case with communications
       technologies, simplification in one element of the system introduces
       a (possibly non-linear) increase in complexity elsewhere.
    NEW
       In an isolated system this may be the
       case; however, as is usually case with communications
       technologies, simplification in one element of the system introduces
       a (possibly non-linear) increase in complexity elsewhere.
    
    OLD
       the cost of increased complexity at a peer network element we loose
       out economically
    NEW
       the cost of increased complexity at a peer network element we lose
       out economically
    
    -- Section 3.6 --
    OLD
       At the very least, the evaluation of these questions constitute a
       cost and introduce delay for the operator.
    COMMENT
    The subject is "evaluation", not "questions", so it's singular.
    NEW
       At the very least, the evaluation of these questions constitutes a
       cost and introduces delay for the operator.
    
    -- Section 4.3.2.2 --
    "straightforward" is one word, not hyphenated.  (Also in Appendix A.5)

draft-betts-itu-oam-ach-code-point

  1. Ronald Bonica: Comment [2012-05-09]:
    As others have said, the specification of multiple OAM mechanisms for MPLS-TP
    does not benefit the community. However, I will not block publication of this
    draft.
  2. Stewart Bryant: Comment [2012-05-10]:
    This document states that:
    
    "A number of experts in the IETF do not consider that the development or
    deployment of a second protocol solution within the same architectural problem
    space is necessary or advisable" and cites draft-sprecher-mpls-tp-oam-
    considerations.
    
    draft-sprecher-mpls-tp-oam-considerations provides many engineering reasons why
    the deployment of a second MPLS-TP OAM is undesirable.
    
    If  G.8113.1 were an IETF document I would have entered a Discuss on this
    enabling document. However, I believe that it is in the best interests of the
    IETF that this decision be deferred to the  government officials charged with
    the responsibility for the approval or rejection of ITU-T Recommendation
    G.8113.1 itself. I request that in applying their wisdom to this difficult
    problem, these government officials do due diligence to the engineering
    consequences of their actions.
    
    I have thus entered an abstain.
  3. Benoit Claise: Comment [2012-05-10]:
    The experts believe that multiple OAM protocols for MPLS-TP is undesirable for
    interoperability, and I agree with that.
    However, I do not think it is in the
    best interest of the IETF to  block the allocation of the code point for ITU-T
    Recommendation G.8113.1.
  4. Ralph Droms: Comment [2012-05-09]:
    I agree with the experts in the IETF cited in this document and with
    the conclusion reached in other documents that it would be desirable
    to have only one MPLS-TP OAM protocol.  Therefore, in my opinion, a
    new G-ACh Type should not be assigned for "G.8113.1 OAM" as requested
    in this document.  However, I will not block its publication and I
    have entered an Abstain position.
  5. Wesley Eddy: Comment [2012-05-09]:
    In the IANA considerations where the value 0x8902 is suggested, it would
    probably be good to note that the rationale is to be consistent with the
    EtherType for Y.1731.  If that value does get assigned, I think it would be good
    to have record of why such a seemingly odd value was picked since there are
    several earlier blocks of unassigned values.
    
    I agree with other ADs that the IETF participants have not expressed a favorable
    consensus for making an allocation permitting multiple OAM types.
  6. Stephen Farrell: Comment [2012-05-08]:
    (This is an agreed text between the two security ADs, in case there's a concern
    its a cut'n'paste error.)
    
    While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15
    did approve the contents of RFC 5586 and in that RFC it requires that relevant
    associated channel type specification include security considerations.  The
    latest version of G.8113.1 available to me does not include a security
    considerations section.  It's unclear why G.8113.1 doesn't include the agreed to
    section.
    
    If G.8113.1 was an IETF draft, I would have entered this as a Discuss because
    G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as
    there are two OAM solutions I consider the one that does address security
    considerations to be the superior solution.  In addition, experience in the
    Security Area has shown developing two standards for the same thing is damaging
    and that that damage persists in the long term, so I believe that the current
    situation with two OAM solutions represents a bad outcome.
    
    However, I do not think it is in the best interest of the IETF to block the
    allocation of the code point for ITU-T Recommendation G.8113.1 based on this
    point.
  7. Russ Housley: Comment [2012-05-07]:
      I believe that multiple OAM protocols for MPLS-TP is undesirable;
      however, I do not think it is in the best interest of the IETF to
      block the allocation of the code point for ITU-T Recommendation
      G.8113.1.
  8. Pete Resnick: Comment [2012-05-08]:
    We have a situation here where we are being asked for IETF-wide approval of a
    code point allocation for a protocol that we have never seen, and a protocol
    that the present document says "a number of experts in the IETF" think is not
    "advisable". Though there was minimal objection during IETF Last Call, I'm not
    completely convinced we would have considered this "in the rough" part of the
    rough consensus under normal circumstances. However, I think calling it "rough
    consensus" can be justified, and therefore I'm uninclined to argue about it
    further. That said, I abstain.
  9. Robert Sparks: Comment [2012-05-09]:
    I don't believe what this code point represents is in the best interest of the
    Internet, but also don't believe further changes to this document will improve
    the situation so I am abstaining.
  10. Sean Turner: Comment [2012-05-07]:
    While the IETF can't dictate the contents of G.8113.1, it appears that ITU SG15
    did approve the contents of RFC 5586 and in that RFC it requires that relevant
    associated channel type specification include security considerations.  The
    latest version of G.8113.1 available to me does not include a security
    considerations section.  It's unclear why G.8113.1 doesn't include the agreed to
    section.
    
    If G.8113.1 was an IETF draft, I would have entered this as a Discuss because
    G.8113.1 does not meet the requirements of RFC 5586 (nor RFC 2223).  Further, as
    there are two OAM solutions I consider the one that does address security
    considerations to be the superior solution.  In addition, experience in the
    Security Area has shown developing two standards for the same thing is damaging
    and that that damage persists in the long term, so I believe that the current
    situation with two OAM solutions represents a bad outcome.
    
    However, I do not think it is in the best interest of the IETF to block the
    allocation of the code point for ITU-T Recommendation G.8113.1 based on this
    point.

draft-irtf-dtnrg-prophet

  1. Stewart Bryant: Comment [2012-05-10]:
    I thought that this was an interesting and novel experimental routing protocol
    and am thus voting yes.
    
    I intend to read it in close detail a further time, and if I have any comments
    that may improve the text, I will pass them to the authors and ISE.
  2. Benoit Claise: Comment [2012-05-10]:
    Slightly surprised by "No objections to its publication as an RFC were raised."
    in the abstract!
    If it passes the IESG, it's because no objections were raised.
    So it doesn't make sense in the abstract of this future RFC ;-)
    
    Along the same lines, not sure if it's appropriate to have the following
    sentence in the abstract: "This document is a product of the Delay Tolerant
    Networking Research Group and has been reviewed by that group."
    The RFC-editor
    should take the final decision on this one.
  3. Adrian Farrel: Comment [2012-04-30]:
    The following comments are provided for consideration by the ISE and 
    document authors in case they can be used to improve the document.
    
    I think that some clarity could be added to the IANA work by
    clarifying the meaning of "Experimental" ranges and other ranges (using 
    the 5226 allocation policies) in the light of this document itself being 
    an Experimental document.
    
    ---
    
    PRoPHET is an Experimental protocol. That is good. Implementers and 
    researchers would benefit from some description and advice on how best
    to experiment with the protocol. What constraints should be applied in
    terms of interaction with "the Internet"? What sort of information 
    should experimenters be hoping to gather? What further protocol work 
    is needed? How would we assess whether PRoPHET is worthy of
    standardising?
  4. Stephen Farrell: Comment [2012-05-08]:
    For this I'm either yes or else I recuse if that's the proper thing for an IRSG
    member
    and RG co-chair to do. I guess nobody knows (or cares:-) so I'll at least
    temporarily
    set a positive precedent.

draft-irtf-rrg-ilnp-noncev6

draft-irtf-rrg-ilnp-icmpv6