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

Roll Call 1134 EDT Amy:

Bernard Aboba--- regrets (IAB meeting)

Richard Barnes--- regrets

Ron Bonica--- present

Stewart Bryant--- present

Gonzalo Camarillo--- present

Benoit Claise--- present

Michelle Cotton--- present [Call-in user 11

Ralph Droms--- present

Wesley Eddy--- present

Adrian Farrel--- present

Stephen Farrell--- present [Call-in user 9]

Sandy Ginoza--- present

Brian Haberman--- present

Joel Halpern--- regrets (IAB Meetnig)

Susan Hares--- present

Russ Housley--- present

Barry Leiba--- present

John Leslie--- present

Pearl Liang--- present [Call in user 12]

Cindy Morgan--- regrets (IAB meeting)

Ray Pelletier--- regrets

Pete Resnick--- present

Robert Sparks--- present

Martin Stiemerling--- present

Sean Turner--- present

Amy Vezza--- present

Bash the Agenda

Amy: Any changes or bashing.

[silence]

Amy: nothing added

Approval of the Minutes of the past telechat

April 26 minutes--- minutes approved and will be posted;

April 26 narrative minutes--- minutes approved;

Review of Action Items from last Telechat

Michelle Cotton, Brian Haberman and Ron Bonica to figure out how to fix the V6 Special Use Registry.
Michelle: still in progress.

Barry Leiba to check whether Mark Nottingham and Julian Reschke wish to continue as experts for the Link Relations registries.
done: Mark and Julian will continue as experts.
Michele: Will you send the official note?
Amy: Should have been sent 1 week ago.
Michele: Let's take off-line determining the status of the offical note.

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?"

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, [...]"

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.

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?

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.

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.

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.

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.

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:

[Amy]:Adrian - A few DISCUSS exist? Any discussion needed?

[Adrian]: No additional discussion. Thank you for comments. Please placed in revised ID

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.

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?

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

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)

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.

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.

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)

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:

[Amy]: Informational RFC, and the token is Wes. I have no DISCUSSes. Any objections?

[Wes]: Authors will make changes. Approved, announcement to be sent, point raised, write-up needed.

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

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)

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.

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.)

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.

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)

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.

[Pete]: I want to confirm that there will be other WG referencing this document.

[Martin]: The CDNI WG is already using this document.

[Pete]: My concern is not with the past. In the past, the other WG used the information and could have used the protocol specification, but the protocol was not there yet.
My concern is with the future. Will future people look to protocol specification or requirements?

[Martin]: Some things in the protocol specification are unclear, and cleared up in this informational specification.

[Pete]: I'll clear that portion of my DISCUSS as it appears to be addrssed.

[Adrian]: Sebastian and I seem to be engaged on closing on all the minor textural comments. The thing you (Martin) as the AD
should focus on is the requirement to use TCP. Sebastian states the previous AD demanded TCP.

[Stewart]: I am confused about that as well. I can see nothing here that requires TCP.

[Martin]: ALTO is a completely different timescale. Originally we had people coming and requiring the congestion control.

[Stewart]: There are three TCP-like protocols that are congestion aware.

[Martin]: Version 14+ indicates this point. Do you have this text? It should allow STCP.

[Stewart]: Why must it be congestion aware?

[Martin]: The data must be there in order for us to provide ALTO flow..

[Stewart]: Why must we be able to have stupid or slow things be TCP congestion aware? Why penalize the small things? in these caes, the bandwidth is known to be small.
Or networks are well-engineered to avoid congestion. We had the same arguments around IPFIX. Why not just write
an applicability statement for these devices. We had the same argument around IPFIX.

[Martin]: As AD, we want devices running TCP which are congestion aware.

[Stewart]: It is the case that all stupid/slow things need TCP congestion aware?

[Martin]: Is your argument that case with the small/slow/stupid things should not be congestion aware?

[Stewart]: Yes let's exclude them.

[Martin]: Are their people who are doing things which are not congestion aware?

[Stewart]: You are not providing a all-encompassing with ALTO?

[Martin]: Are you arguing the Internet should not be congestion aware?

[Stewart]: The whole system should be congestion aware, but not all devices?

[Adrian]: For such a device, why it would be running ALTO?

[Benoit]: I also do not see any ALTO running in such small devices?

[Stewart]: Why can't we get around this via IP-fix? "Should", but engineer if you don't.

[Martin]: Are you asking why we specifying the trasnport requirement instead of real issue?

[Stewart]: Why do we not congestion transports? why not any particular transport?

[Adrian]: I think if you address it Wes as the layering of the base requirements and layers upward, you will answer these points.

[Wes]: OK,

[Stewart]: Different deployments have different concerns. I'm not sure you can commit to any particular transport at this point... "must not do harm to congestion"

[Benoit]: in IPFIX several MAY transport Stewart: different areas with different concerns... I disagree with the way this comes out specifying particular (transport) protocols

[Wes]: I agree that we can work on the text.

[Benoit]: I will agree as well.

[Wes]: What about Benoit's DISCUSS?

[Benoit]: I agree with Adrian, there is no real requirement for operations and management.
The document just says this must be compliant with RFC 5706. However, this document is a
document which asks you the right questions. So ideally this protocol document should have a section
with operational and configuration issues from RFC5706 that are necessary.
If there are none, than this is ok.

[Wes]: You are not looking for something detailed, but you need something with
adequate requirements?

[Benoit]: I keep hearing "don't want OAM not because we don't know how it will be used"

[Martin]: It is entirely correct to say "must think about it." if we come to protocol document with OAM
you should send us back

[Benoit]: without mention in requirements, it tends to get ignored, just "look at RFC 5706" doesn't seem enough
detail at this point.

[Martin]: Would this text work for you?
"Req ARV?? - An Alto protocol must provide adequate mechanisms for operations and management
for operations and management support, as outlined in RFC 5706."

[Adrian]: I did respond to this as a requirement. I'm OK if the protocol does do all of RFC 5706. However, I
suspect only part of the requirements in RFC5706.

[Martin]: They need to provide adequate mechanisms out of RFC5706. It would be harmful to mandate
all of the details on RFC5706. We could specify the statements like service-block informaiton.
We feel that the AAA and the other WG seeing that they can use ALTO to determine whose sending or using the video.

[Benoit]: Someone I keep hearing that the author is afraid to commit to a management information.

[Wes]: We have a requirement to consider the management. We cannot have a protocol with not management.

[Benoit]: If you do not put management in the requirements, you will get protocols which do not have it.

[Martin]: This RFC was called to my attention regarding having the [nm] protocol.

[Benoit]: It is not good enough to have RFC5706 as the protocol. I will object to any protocol without NM.

[Adrian]: Isn't true that the protocol ID is on its 12th revision? Therefore the protocol form is fairly well know.
If you were going to have a solution that says the next revision of the protocol must have the NM in the protocol
by the next revision.

[Wes]: I will tell them that they must network management.

[Benoit]: I will review the protocol and evaluate against RFC5706.

[Wes]: Stephen has a question as well.

[Stephen]: I can do it via email.

[Wes]: If you can do it by email, I think all people would appreciate it.

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?

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.

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].

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.

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.

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.

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.

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?

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.

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)

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.

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".

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.

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.

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?

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)

[Amy]: We do have a number of DISCUSSes in the tracker. Shall we discuss it here?

[Gonazalo]: The first thing is the language issues by non-native speaker. We found it not issue for implementating the draft.
We felt is was implementable. The native English speaker will improve the English in the document
after we finish the technical point. We have had changes that we are discussing with the shepherd.
After the technical changes and the textual editing, we'll send back to WG and do WG LC.
We'll follow Stewart request to bring this back to another telechat.

[Stewart]: Then it would bring it back for another telechat?

[Gonazalo]: The scope of the draft may have caused a lot of confusion.
You can see implementation with RTP splicing on the draft. This draft
suggest how to do this uing standard RTP. This is an informational
document that discusses how this is done.
The author may be unclear with the draft.

[Stewart]: Are there three SDOs working on this?

[Gonzalo]: I can check that, I know WG is checking implementatinos.

[Stewart]: These other SDOs should be examining this as well.

[Gonzalo]: I can give this background to the shepherd, but I understand you'll
want to review after the changes, and I expect another WGLC and perhaps an IETF LC.

[Gonzalo]: Please put in revised ID needed.

[Pete]: Do want to have this done in the focus of this DISCUSS or should we
just pass our input to the shepherds?

[Gonzalo]: The feedback is welcome to be sent to the shepherd and the WG
I will have the draft revised.

[Pete]: Will this go to WG LC or IETF LC?

[Gonzalo]: WG last call is likely to be repeated.

[Stephen]: For what they want to do, does it have to break the ETE security?
Is it possible to have the End-to-End (ETE) protection work with the RTP input?

[Gonzalo]: If you have a weak protection for the mixer ETE, it is possible. With strong ETE
it is not possible because they do not have the calls.

[Robert]: The phone calls are generally unicast.
This protocol suggest that the information is sent via multicast, and
this requires security. The user is asking for content from a mixer, and there
is no hope of integrity beyond the mixter. It would be difficult to insert a
rogue mixer.

[Gonzalo]: Source identification is the mixer, anybody working on RTP knows this.

[Stewart]: Would it make it easier to subvert such a stream?

[Russ]: The mixer is the component that has the issue.

[Robert]: The attacks on the protocol are stopped by the forwarding.

[Stewart]: I'm sitting in a router, can I attacking the stream?

[Gonzalo]: You can break it in many ways. The question you raised indicate
that the generalist cannot read this without a bit of explanation.

[Stewart]: Does the mixer automatically reset sequence numbers.

[Robert]: The sequence space between the send and mixer, and another between mixer and
receiver. The control is completely in the hands of the mixer.

[Stewart]; The mixer resequences.

[Gonzalo]: The RTP knows that peope know who is in control of the sequences spacse.

[Stewart]I would use hate to make it easier for bad governments or bad individuals might attack.

[Gonzalo]: It is important to have nothing undermine the security connection.

[Gonzalo]: Thank you for your comments on the draft. Revised ID needed.

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.

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:

(version -05 submitted this morning)

Amy - No open discusses, and comments.

Gonazalo - A version 5 was released this morning so it covers all the comment. It can now be approved directly. We are not in a hurry.

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.

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.

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)?

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.

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:

[Amy]: There are DISCUSSES. Ron Do we need to discuss the document.

[Ron]: The authors agreed with the comments, and agreed to update the document. Will do so when return from vacation.

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.

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/

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 ..."

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

[Amy]: There are no DISCUSSES on the document. One yes, despite many abstains. Is this approved?

[Pete]: May we try to convince the "Yes" and the "No Objection" people to abstain?

[Russ]: It is approved.

[Amy]: Are the notes correct?

[Adrian]: I would like to have you pay attention to the notes.

[Michelle]: I would like this information. Is this the document we're holding off action to work on?

[Adrian]: Yes, I want this document not to be publish until the ITU document is published.
Until that time, we do not want to hint what code point/RFC will assigned.
When the ITU announcement comes, then we will publish it.
It may be appropriate to to the AUTH48 work ahead of Time.

[Russ]: We have no objections with getting to AUTH48, then putting in IESG hold.

[Sandy]: We can put it in AUTH-48 with a few TBDs.

[Russ]: That works.We have a reference to the ITU document that we cannot resolve and do not have a date for the completion.

[Michele]: For IANA, we can actually put it on hold.

[Pete]: Why not put this not put in misref to protect their statistics?

[Sandy]: Mis-ref takes it out of our registry. On hold.

[Adrian]: The IESG should put a note on this document due to the double digit abstains.

[Russ]: I'm not sure we should go to the additional text.

[Stewart]: It is not unreasonable.

[Adrian]: The draft-sprecher has a reference to draft-betts. I am concerned that the ITU will
provide a PR release that says the IETF supports an ITU code point.

[Russ]: I do not see how they can read the document and say this. I would happier with
a statement of IETF RFCs should be used.

[Adrian]: You are saying that the base paragraph is good, and the additional text is not.

[Pete]: suggest: first sentence as is, then "not endorsement", end with IESG recommends instead?

[Adrian]: I have those changes. Other thoughts?

[Stewart]: I'd like government types to understand technical issues haven't been resolved.

[Russ]: We have not succeeded in the Last 18 months, and the

[Stewart]: Just because you have not succeed, you should not abandon your principles.

[Russ]: I would advise against putting in this in the RFCs.

[Stewart]: WE indicated that there engineering issues brushed aside.

[Robert]: Indeed we have documented this in this document.

[Stewart]: I would have said that a wider community would disapprove.

[Russ]: I've voiced my opinoin

[Adrian]: I've put in the jabber room. the following "The IESG notes that the IETF has deeloped a set of
OAM tools for MPLS-TP that have been published as STandards Track RFCs. A list of the relevant RFCS
cab be found in RFC xxx. The approval of this document and the assignment of the ACh type does not
consititute endorsement by the IETF of the Alternate MPLS-TP OAM documented in the G.8113.1. The IESG
recommends instead that the RFCs noted above should be implemented.

[Russ]: Stewart can you live with this text?

[Stewart]: I would have gone with stronger language, but I can live with this text.

[Barry]: works for me.

.. Agreement form many members

[Stewart]: Will the IESG note go otu with the announcement.

[Russ]: Yes it will

[Amy]: I do have all the announcement notes ready. This document will be released.

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.

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.

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?

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:

[Amy]: The

[Michele]: The IANA Section is not completed so we'll need a hold.

[Amy]: Do you want to hold this in approved, announcement sent, point raised, up write?

[Adrian]: This is good,and I'll rely on IANA to kick me to kick start this.

[Amy]: Token is Pete. Does any one have an objection to creating Weirds?

[Pete]: There are two comments on the mailing list that I sent it out as is.
There is a comment from Eric Brunner-Williams that I cannot make actionable.

[benoit]: I am concerned about the working group about the "names of the service". I am
unclear if this is an HTTP service. "You shall determine the needs" is the sentence.
What is the sense of this text? Is it I am not a native speaker.

[PEte]: We have some general needs, but we need a more specific set of needs. We'll need to build
the general framework document.

[benoit]: What specifically needs to be done for this?

[Pete]: They know they will use a RESTFul interface for this document.

[Benoit]: Not being a native speaker, if this is fine. I'm ok.

[Pete]: As soon I confirm with Co-chairs, we can send out this announcement.

[Amy]: The wierds charter is approved pending the confirmation for co-chairs

[Pete]: yes

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

Behavior Engineering for Hindrance Avoidance (behave)
Token: Wes

Telechat:

[Amy]: Any objection to just making changes to charter?

[Wes]: I need to adjust the dates on this charter. Since it has a relationship to sunset4, it must be sent for external review after edits.

[Russ]: Let's do approved, point raised unless someone has comment.

[Benoit]: The draft-sivakumar-behave-nat-logging-02 is an individual draft. It will become a WG draft

[Wes]: This draft was strongly agreed to.

[Benoit]: My concern is that we should reuse the IANA items.

[Wes]: Can you tell me the document meets your approval with this reuse addition?

[Benoit]: yes.

[Wes]: I can fix add the reuse during the date change.

[Amy]: This will be placed in the approved

Web Authorization Protocol (oauth)
Token: Stephen

Telechat:

[Amy]: Can this be approved to just making a change?

[Stephen]: It can be sent if it is approved.

[Amy]: The recharter is approved, and a recharter notice will be sent.

Diameter Maintenance and Extensions (dime)
Token: Benoit

Telechat:

[Amy]: Any objections?

[Benoit]: It would be easy to just remove to two drafts that are dead.
I asked the two chairs to give me the correct milestones for the existing wG items.

[Robert]: what was your questions?

[Russ]: The only thing you need approval is the removal of text.

[robert]: I agree that there is nothing to be gained by external review.

[Amy]: I hear no objections to just sending the charter out.

Network File System Version 4 (nfsv4)
Token: Martin

Telechat:

[Amy]: Does anyone have objections? Should this go for wider review?

[Martin]:This should go for external review with updated milestones.

[Amy]: Any objection? Hearing non the External review is approved to be sent once the milestones have been approved.

Multipath TCP (mptcp)
Token: Wes

Telechat:

[Amy]: Does anyone have an objection, or are the extensions significant for wider review?

[Wes]: This should be sent for external review, and Ron was mulling over some concerns.

[Amy]: Barry designated Arnt Gulbrandsen and David Cridland as experts for the registry.

[Amy]: These experts are approved. Thank you Barry.

Dan Ramascu has posted an IESG response to the IEEE Liaison

Telechat:

[Russ]: One editorial change? Any substantive questions?

[STewart]: There are 2nd order affects that we may or may not want to talk about.
The IEEE uses ISIS and KARP considers security for ISIS. RTRWG which applies ISIS like thing
and may apply to TRILL.

[Russ]: My gut is the first one does (ISIS & KARP). On the second one - I do not know.

[Adrian]: If you consider the first one in, the second should.

[Russ]: See the paragraph at the end of the INT area discussion.

[ralph]: This is different due to no WG actions have happened.

[Stewart]: "areas of mutual interest"?

[Robert]: Dan's approach was to answer the question for liaison. Are the items for a leadership discussion?

[Russ]: Is KARP probably aligned for the the liaison question.

[Stewart]: The KARP is linked the original question.

[Russ]: I can see that it is you are using ISIS. Please don't develop authication algorithsm, we have them.
Stewart can you generate a paragraph about KARP on this?

[Stewart]: I can do that in a few minutes after the telechat.

[Russ]: Does anyone have an objection to approved, point raised knowing that Stewarts and my editorials are coming.

[Amy]: The Liaison is approved, point raised.

7. Agenda Working Group News

Ron Bonica (O & M)--- Wes George has stepped down as chair of RENO and he has been replaced by Lee Howard (?)

Stewart Bryant (Routing)--- no news.

Gonzalo Camarillo (RAI)--- No news.

Benoit Claise (O & M)--- No news.

Ralph Droms (Internet)--- No news.

Wesley Eddy (Transport)--- No news.

Adrian Farrel (Routing)--- No news.

Stephen Farrell (Security)--- No news.

Brian Hamerman (Internet)--- No news.

Russ Housley (General)--- Reminder to people that results of the anti-trust bof that we will be posting
some education material. Marshall Eubanks has taken to the pen into sometime we can put on the iETF web site.

Barry Leiba (Applications)--- no news.

Pete Resnick (Apps)--- EAI is having its iterim on Monday Noon UTC. Core is having its interim on Tuesday at 2pm UTC.

Robert Sparks (RAI)--- no news.

Martin Stiemerling (Transport)--- no news.

Sean Turner (Security)--- no news.

1425 EDT Adjourned

Appendix: Snapshot of discusses/comments

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.

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, [...]

- 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.

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?

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.

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.

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.

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.

- 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.

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?

- 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

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.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.

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".

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.

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

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?

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.

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?

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.)

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.

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.

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.

- 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?

-- 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].

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.

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.

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.

- 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?

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.

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.

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.

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".

(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.

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?

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.

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.

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.

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.

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.

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)?

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.

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.

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.

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
...

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)

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.

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.

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.

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.

(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.

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.

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.

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.

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.

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.

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?