IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-05-10. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
3.3.3 For Action
1254 EDT break
1300 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1425 EDT Adjourned
(at 2012-05-10 07:30:03 PDT)
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, [...]
I support point 2 of Brian's DISCUSS.
- 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.
Please consider the editorial issues raise in the Gen-ART Review by Miguel Garcia on 27-Mar-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07303.html
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 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.
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 consider the editorial issues raise in the Gen-ART Review by Vijay Gurbani on 27-Apr-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07401.html
- 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.
Thank you for considering the minor comments and editorial comments raised by Vijay Gurbani in the Gen-ART Review posted on 8-May-2012.
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.
I agree with Barry that some of the requirements should be re-worded. Otherwise, I have no issues with publishing this document.
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.
Please review Ted's other minor comments in his Apps Directorate review <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03337.html> and address as appropriate.
- 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 , MPLS-BFD , VCCV , and VCCV-BFD ). 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?
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.
(Oops wrong button, I've no objection really:-) - draft-ietf-mpls-tp-security-framework-02, May 2011 was updated by a -03 in October 2011. - weird references, the spaces muck up tools: [MPLS TP ITU Idents] [MPLS-TP Security Frwk] - s/MPSL-TP/MPLS-TP/ maybe?
-- 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].
Section 8., paragraph 3: > Thanks to Rui Costa for his review and comments which helped improve > this doecument. s/doecument/document/
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.
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.
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.
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.
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.
I support the discuss positions from the other ADs.
I agree with the secdir review and Barry's comment about the security considerations and believe this is being handled already.
Please consider the editorial issues raise in the Gen-ART Review by Vijay Gurbani on 27-Apr-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07402.html
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.
"The use of specific multicast addresses for documentation purposes has no impact on security." Actually isn't it a security improvement?
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, 188.8.131.52/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.
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/
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 184.108.40.206 -- "straightforward" is one word, not hyphenated. (Also in Appendix A.5)
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.
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.
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.
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?
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.