IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-09-13. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=NPDV | I |pdvtyp |Rsv| block length=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
pdvtype = "pdv=" "0" ; MAPDV2 ITU-T G.1020 / "1" ; 2-point PDV ITU-T Y.1540 / 1*2DIGIT ;Value 2~15 are valid and ;reserved for future useThat just has to be wrong. This matches:
pdvtype = "pdv=" ("0" ; MAPDV2 ITU-T G.1020 / "1" ; 2-point PDV ITU-T Y.1540 / 1*2DIGIT) ;Value 2~15 are valid and ;reserved for future useThat gets you the right result.
nspec = "nthr=" fixpoint ; negative PDV threshold (ms) / "npc=" fixpoint ; negative PDV percentile pspec = "pthr=" fixpoint ; positive PDV threshold (ms) / "ppc=" fixpoint ; positive PDV percentileThese are fine, but would be clearer with parens.
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
bits 014-011 0: MAPDV2, Clause 188.8.131.52 of [G.1020], 1: 2-point PDV, Clause 6.2.4 of [Y.1540].
3.1.2 Returning Items
+-----------+----------------+----------------------------+ | Flags | Algorithm Name | Reference | +-----------+----------------+----------------------------+ | 0000001 | HMAC-SHA1 | This document, Section 3.2 | +-----------+----------------+----------------------------+
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
???? EDT break
???? 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
1324 EDT Entered Executive Session
(at 2012-09-13 07:30:02 PDT)
As noted in the Gen-ART Review by Roni Even on 22-Aug-2012, at the end of sections 3.7 and 3.8 "acton" should be "action"
I have no objection to the publication of this document. Please consider the following Comments. --- Section 2.1 Only one "imapsieve" capability string, specifying one sieveurl- server, can be present. Are you sure? Or do you mean "More than one "imapsieve" capability string MUST NOT be present"? And then a description of how to process the error case. --- Section 2.2.4 (see also 3.8) In a server that advertises "imapsieve", messages whose flags are changed in any way (except as explained in the next sentence) MUST trigger the execution of a Sieve script, subject to the settings defined through Metadata. The exception is that in order to avoid script loops, flag changes that are made as a result of a script that was itself invoked because of flag changes SHOULD NOT result in another script invocation. In any case, implementations MUST take steps to avoid such loops. Yes, the script recursion or loop is to be avoided. But isn't what you have here too strict? Might you not have a script that reacts to a flag (X) that is set by a command. That script sets another flag (Y). Then you want a script that reacts to flag (Y) being set. I think you probably only need that a script MUST NOT be invoked more than once in the sequence of events following a "top-level" event (presumably a command or "cause" in the language of 4.3). Noting that 2.3.1 has: Only one Sieve script may currently be defined per mailbox, I wonder whether this debate is moot. --- Section 2.3.1 Support for IMAP events in Sieve requires support for IMAP Metadata [RFC5464] as well, since the latter is used to associate scripts with IMAP mailboxes. Want to play with that so it is in 2119 language? --- Section 3.3 If a keep action is NOT also in effect, the original message is then marked with the \Deleted flag (and a flag-change Sieve script is NOT invoked). I don't think the emphasis of uppercase "NOT" is needed. We find similar text in 3.4 and 3.5. --- Section 3.3 (this paragraph is having a bad day) The implementation MAY then expunge the original message (WITHOUT expunging other messages in the mailbox), or it MAY choose to have expunges batched, or done by a user. I find this ambiguous. I cannot tell whether one of the three actions MUST be selected, or whether each action is OPTIONAL (and mutually exclusive). We find similar text in 3.4 and 3.5. --- 3.11 Future extensions that are specifically designed to respond to delivery of a new email message will likewise not be applicable to this extension. This is fine, but I wonder whether you want to move this text to a new subsection "3.12 Future Seive Actions". In that section, I think you also want to require that new specifications of Seive actions must specifiy their interaction with the function defined in this document.
See earlier DISCUSS on -06, "solved" in -07;-)
Can the document make it clearer that actions like fileinto don't trigger the script associated with the mailbox being filed into? That is, make it clearer that ONLY IMAP events cause these scripts to be called. There are places where loop prevention is discussed that currently focus only on flag changes. Should they encompass all IMAP events that cause these scripts to be run? (Can a script cause an IMAP COPY to happen)?
Please check example 2 - it should only fire when the flagged flag is set. From a conversation with Barry, the 'not' in the condition may be wrong. Section 3.4 speaks of a message submission server possibly rejecting a script's submission attempt. Is there anywhere it can point to for advice on how the sieve implementation should let the script user know that happened? The environment names live in a global space - other extensions might want to put a cause into the environment. Would it be worth the pain to scope the name _this_ extension is adding to this extension ("imapcause" or something like that)?
supporting Adrian's DISCUSS
Thanks, this is a well-written and easy-to-read document. Just a couple (well, three) of small issues that I would like to Discuss. --- Surpised that there are no requirements on authetication or control of admission to chat rooms. Was this topic discussed by the WG and left out on purpose (in which case we should add a note to that effect), was it forgotten (in which case we should address it), or is it not relevant for this type of chat (in which case you just need to explain it to me)? I would assume that the INVITE can be policed in some way. The best I could find was in Section 5.2 Participants usually join the chat room by sending an INVITE request to the chat room URI. As long as the chat room policy allows, the INVITE request is accepted by the focus and the user is brought into the actual chat room. Indeed, there are several mentions of things being allowed according to chat-room policy, but no wider discussion of the full set of policy attributes, or how chat room policy is set. --- Section 6.1 On sending a regular message the sender MUST populate the To header of the Message/CPIM wrapper with the URI of the chat room. The sender SHOULD populate the From header of the Message/CPIM wrapper with a proper identifier by which the user is recognized in the chat room. I'm uncomfortable with the "SHOULD" here. It implies that you can think of a good reason why the sender MAY use some other (improper) identifier or no identifier at all. Can you either give an example (perhaps: "The sender MAY set an arbitrary and meaningless value in order to hide its identitiy"), or tighten the SHOULD to a MUST. --- Section 6.1 An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-Id of the MSRP message to correlate the different chunks, as well as it MUST temporarily store the list of recipients to which the initial chunks were delivered. The motivaiton is clear. I think you could add that the storage can be released when the last chunk is seen. But what happens when the last chunk is not seen (or delayed)? How temporary is the storage, and how is it released? Or do we assume that because MSRP uses TCP (or similar) that loss will always be accompanied by connection failure and so that is the only trigger needed to abandon temporary storage?
Section 4 In order to enter a chat room, one must first be created. Obviously, I spend to much time hanging out with the Queen, but when you say "one must be created" I suspect you meant the chat room, not one's self. Maybe reword as... Before a chat room can be entered, it must be created. --- Section 6.1 (trivial nit) The SEND request MUST contain a top-level wrapper of type 'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual instant message payload MUST be included as payload of the 'Message/CPIM' wrapper and MAY be of any type negotiated in the SDP 'accept-types' attribute according to the MSRP rules. I think s/MAY/may/. That is, a type must be set, and the type must be only one of those that has been negotiated.
Section 1 says: Similar conferences supporting chat rooms are already available today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat rooms, and many other proprietary systems provide chat room functionality. Specifying equivalent functionality for MSRP-based systems provides competitive features and enables interworking between the systems. I do not think this document enables interworking; at least I don't think there's sufficient information here to justify that claim. Further, I don't think the motivation given here suffices to do yet-another-messaging-protocol, simply because N others already exist. Particularly, with regards to existing IETF Standards Track protocols, I think there needs to be better motivation for adding yet another. It might help me clear if there was some description of how this is being used in practice or whether people really are doing interworking.
My comments are related to the congestion avoidance section. I think it needs to be tweaked somewhat, as the recommendations are not really effective. However, I don't feel the need to make this a DISCUSS, because in the end, the authors are right that TCP is protecting the network paths ... the only downside to doing things poorly (i.e. using the current recommendations in the document) is suboptimal performance in the application. So it will be in the WG's best interest to improve this, but it won't cause the Internet to fail. Section 6.4, in the first paragraph, I think the motivations are misguided. The issue is not fast or slow paths, but rather the total loading of traffic on the paths from this and other applications. Also note that the messaging applications do not really send at any "rate", since message flow is highly asynchronous. I believe that the buffers discussed in this section need to be sized such that nominal bursts of messages can be accommodated arriving asynchronously, and with the understanding the overly large buffers in comparison to the link rate will create excessive delay to be shared by all other messages on that TCP connection due to head-of-line blocking. The first suggestion of sending messages to let a destination know that it's TCP connection is congested seems to be a bit counter-productive. It's equivalent to sending emails to someone to inform them that their inbox is full. Also not that inferring congestion via the length of the TCP send buffer is not quite so easy to do as the document assumes. First of all, the send buffer's length is not part of the typical TCP API, so you're likely going to need OS-specific ways of accessing this. Further, all this means is that you have pending data, not that there's actually congestion on the network path which is causing losses. You could be getting serious congestion and losses without the send buffer growing to the high-water mark defined, or due to a limited advertised receive window, you could be throttled by the receiving application and not losing packets at all inside the network.
These should all be very easy discuss points to resolve. 1. 5.2, what is an "anonymous URI"? What kind of anonymity is being provided here? I think you need at least a reference or else to get rid of the paragraph or else provide more text that says how it might work so that a client could implement it with a reasonable expectation that a server will be ok with it. 2. p13, SHOULD start the distribution process as soon as the first chunk is received is a potential DoS vector. How is that mitigated? I think adding a sentence or reference to the security considerations would be enough here, e.g. saying that servers SHOULD implement some sanity checking in such cases. MSRP's security considerations say it can't be used as a DoS amplifier, but I guess this can based on the above. (This is similar to, but not the same as, Adrian's last discuss point.) 3. Where are the security considerations about unsafe content? E.g. HTML scripts that are phishing attempts. Again, I think a reference to some other document or small bit of text is needed. 4. Cleared. This AD is sometimes dim:-) 5. (Promoted from a comment at the request of an author, so it gets tracked.) Everyone sends an 'accept-types' attribute, right? Is it clear what happens if an IM containing a CPIM containing a payload with a MIME type that's not supported everywhere is sent to all?
- I agree with Adrian's first discuss point about the need to better reference or describe how policy stuff can be done here. - Don't we prefer one protocol for each thing in general, so why not say that? That is, shouldn't we say somewhere that, in general, folks ought use XMPP but that this protocol is useful for SIP-oriented deployments? (Apologies if I've stirred a hornet's nest but I think we prefer XMPP, based on our own usage at least.) - section 1: Saying that this "provides competitive features" to XMPP seems wrong, I'd suggest deleting that phrase. - section 1: it wasn't clear to me if "interop" here is being used just for SIMPLE clients and servers or more broadly to mean interop with other chat services, in particular XMPP. I assume you mean the former. - section 1: Is the last sentence saying this is a short-term solution only or that this is something that'll be available soon? The latter would be fine (if true) but the former would seem problematic without more warnings for implementers about when they may need to replace this. - section 2: it might be good to note explicitly that a "private" IM is seen by the server and isn't only seen by the sender and recipient. - section 3 talks about the "identifier" of a sender or recipient, but that's not a term defined in section 2. It'd be better to clarify that I think. - s4, p10: s/is logged/is logged in/ and do you need to define what you mean by "logged in" in section 2? (Not sure, its fairly clear I think, but this is the first time you've said I can be connected more than once.) - last para of section 8: Just noting that I expected the extension to be called "foo.chat" given the reversal of example.com. Is the text correct? - Section 8: should you note that implementations cannot assume anything about similar private extension names because they won't know which bit is the DNS name and which is the extension name? i.e. uk.co.bbc.foo.bar and ie.tcd.foo.bar don't tell me that both are doing foo.bar (or bar.foo;-)
A small but important matter - my compliments to the document shepherd for the well-written and comprehensive description of the working group process and document review for this document, and for the due diligence I infer on the part of the document shepherd in preparing the writeup and document for IESG review.
I have no general concerns with this draft, but one discuss issue: Section 6.4. Congestion Avoidance I am not sure that you are really discussing congestion in the sense of network path congestion (including end hosts), but this is more about overload handling at MSRP nodes IMHO. It is a different level where the congestion can occur, i.e., in the MSRP application. A cause for congestion at this level can be a congested network path. The reasons are that there are number of cases why message(s) to a certain MSRP receiver/agent cannot be delivered, e.g., : - TCP cannot deliver in-time, as the network path or the receiving system are congested - the particular interface is down - the IP address used for the TCP connection is just gone - the DNS resolution for the FQDN in the SIP URI just takes too long - (as you noted) the sender is sending with a rate that cannot be received by a receiver - the at other end is overwhelmed with the processing of the messages How should an MSRP node react to them, e.g., how to deal with nodes that are constantly overloaded by receiving messages? Did you actually check back with the SIP overload control work? This said, a section about overload handling is good to have.
Section 2., paragraph 8: > Recipient: the destination chat room participant(s). This defaults > to the full conference participant list minus the IM Sender. Expand 'IM' on first use. > REQ-2: A recipient of an instant message in a chat room must be able > to determine the identifier of the sender of the message. > Note that the actual identifier depends on the one which was > used by the sender when he or she joined the chat room. A complete nuts nit: what if the sender isn't he or she, but a sensor? Also interesting in conjunction with Section 6.4, i..e. how to tell such a machine to stop sending?
5.2: The conference focus of a chat room MUST learn the chat room capabilities of each participant that joins the chat room. The conference focus MUST inform the MSRP switch of such support in order to prevent the MSRP switch from distributing private messages to participants who do not support private messaging. The first MUST is superfluous. Try this instead: The conference focus of a chat room MUST inform the MSRP switch of the chat room capabilities of each participant that joins the chat room in order to prevent the MSRP switch from distributing private messages to participants who do not support private messaging. There are a few other examples of such superfluous uses below, but I'm sure I didn't catch all of them. Please review for places where the 2119 keyword is being used (incorrectly) for a description of the behavior instead of (correctly) for the protocol requirement. 6.1: The actual instant message payload MUST be included as payload of the 'Message/CPIM' wrapper Silly MUST. Instead: "The payload of the 'Message/CPIM' wrapper will be the actual instant message payload." An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-Id of the MSRP message to correlate the different chunks, as well as it MUST temporarily store the list of recipients to which the initial chunks were delivered. Why does the switch have to store the Message-Ids and recipients? Is it so that it can figure out which recipients got which messages? If so, then these are not protocol requirements. In order to accomplish the protocol requirement ("SHOULD forward subsequent chunks only to..."), the switch "will need to" store these things. An MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM wrapper. If the To header field is set to the chat room URI, it should render it as a regular message that has been distributed to all the participants in the chat room. Then the MSRP endpoint SHOULD inspect the From header field of the Message/ CPIM wrapper to identify the sender. Why SHOULD the endpoint inspect the headers? Again, I suspect that the *inspection* is not the protocol requirement. I'm not even sure I know what is in this paragraph. 6.2: Then the MSRP switch MUST inspect the To header field of the Message/ CPIM wrapper. Superfluous sentence, let alone superfluous MUST. Delete. Then the MSRP switch MUST verify that the To header of the Message/CPIM wrapper matches the URI of a participant of the chat room. Same as above. Finally, the MSRP switch MUST verify that the recipient supports private messages. Same as above. It is RECOMMENDED that the MSRP switch can map a URI to two or more MSRP sessions. It is "RECOMMENDED" that the switch "can" do something? That doesn't make sense. 6.3: MSRP switches MUST follow the success report and failure report handling described in section 7 of RFC 4975 [RFC4975], complemented with the procedures described in this section. The MSRP switch MUST act as an MSRP endpoint receiver of the request according to section 5.3 of RFC 4975 [RFC4975]. Wouldn't this be better as: The MSRP switch is an MSRP endpoint receiver of the report requests as described in section 5.3 of 4975 and will follow the report handling procedures described in section 7 of 4975, complemented with the procedures described in this section. 7: First it says: Therefore, if a user joins the chat room under the same URI from multiple devices, he or she may request the same nickname across all these devices. Then it says: This memo specifies the nickname as a string. The nickname string MUST be unambiguous within the scope of the chat room (conference instance). These two statements seem like they are in conflict. I think a bit more explaining is in order. Can I use the same nickname across all devices or can't I? 7.1: This mitigates the problem of nickname duplication, but it does not solve a problem whereby users can choose similar (but different) characters to represent two different nicknames. For example, "BOY" and "B0Y" are different nicknames which can mislead users. The former uses the capital letter "O" while the latter uses the number zero "0". In many fonts the letter "O" and the number zero "0" might be quite similar, and difficult to be perceived as different characters. Chat rooms MAY provide a mechanism to mitigate confusable nicknames. I don't see how this discussion is really necessary. Whether confusables are an issue at all is a completely implementation specific detail, not a protocol issue. In addition to preparing and comparing following the rules above, the MSRP switch SHOULD validate that the SIP AOR identifying the user is entitled to reserve the nickname. This may include, e.g., allowing that the participant's URI may use the same nickname when the participant has joined the chat room from different devices under the same URI. The protocol requirement is not to validate that the user is entitled to reserve the nickname. The protocol requirement is that the MSRP switch SHOULD only allow the registration of a duplicate nickname if the same user that is currently using the nickname is making the second request. As written, this is confusing. If the MSRP switch is able to accept the suggested nickname to be used by this user, the MSRP switch MUST answer the NICKNAME request with a 200 response as per regular MSRP procedures. MUST? No, I think that's a MAY. Why would it be a MUST?
I'll trust the 5 DISCUSS from my IESG fellows on this document.
I was very much on the fence about whether to ballot ABSTAIN or NO OBJECTION. It's clear that a lot has happened in the eight and a half years since this larva hatched, and the five since it pupated as a working group document. I don't think the result is a butterfly; rather, it's been overtaken by events, and I'm not at all sure that it's best for the Internet to standardize this. There are lots of instant messaging systems out there, and picking yet another about which to say, "This is a Proposed Standard," is questionable, I think. In the end, because this isn't defining the IM system from the start, but is layering chat-room function on top of what's already there, and because it's been implemented, I've decided to go with NO OBJECTION. To be clear: None of that internal debate I was having with myself had anything to do with the quality of the document. It's a fine document, well written, and I appreciate the time spent on it over the many years. We frequently have documents that are so long in the making that we don't want to abandon them, and this is only one. So carry on, and I have no official objection to seeing this finished. Apart from what Adrian caught, there's one very minor editorial thing that I noticed while I was reviewing: -- Section 11 -- If a participant wants to avoid eavesdropping, the participant's MSRP client can send the messages over a TLS [RFC5246] transport connection, as allowed by MSRP. It's up to the policy of the MSRP switch if the messages are forwarded to the other participant's in the chat room using TLS [RFC5246] transport. The first clause is ambiguous, and when I first read it I thought it was talking about the participant not wanting to *be* the eavesdropper. I suggest re-wording it. While you're at it, you can take that stray apostrophe out of "participants" at the end. Oh, also... In Section 12, I know that at least one of the Contributors has changed affiliations. Have you checked with them to make sure the affiliations you list are what they want to have there now?
I have no problems with the publication of this well-written document. I do support Adrian's first two DISCUSS points.
1) REQ-4 and S8: I'm confused by the following in s8: For example, a participant would like to learn if the MSRP switch supports private messaging, otherwise, the participant may send what he believes is a private instant message addressed to a participant, but since the MSRP switch does not support the functions specified in this memo, the message gets eventually distributed to all the participants of the chat room. Aren't servers required to support private messages? I get that clients might not support 'em, but based on REQ-4 don't servers have to support 'em?
1) So this is probably a .0001% case (maybe need some more zeros there :), but it might be worth mentioning that clients who use TLS client side certificates with real names in the certificates won't be anonymous to whatever server they connect to. The name in the certificate might not get used by the MSDP protocol but the server will have the certificate with an actual name in it. 2) s8: Had trouble parsing the following: In this type of extensions, are must be taken in the selection of the token to avoid a clash with any of the tokens previously defined.
As noted in the Gen-ART Review by Peter Yee on 6-Sep-2012, Section 4, 1st paragraph, 3rd sentence: "identifies" -> "identify".
I wish I didn't get the feeling that someone is missing something everytime I read the security considerations section for MPLS documents. To be honest, it all just seems like too good a deal, basically not having to worry about bad actors. (Note: that's a general lament/whinge, not specific to this document. Sorry about that;-)
My Discuss issues should be easy to resolve. In my opinion, a little more detail could be provided in section 5 to give guidance about backward compatibility when deploying the extended ASSOCIATION objects described in this document. First, an editorial nit: the third sentence is vague - what, exactly, is "essentially also the action taken for unknown association types" and where is that behavior specified?. Second, I suggest it would be helpful to note that RFC 2209 requires the generation of an error message for unknown C-types, so a deployment of the extended ASSOCIATION across devices that don't implement the new C-type will be indicated explicitly. Finally, are there any compatibility issues with a node that implements RFC 4872 ASSOCIATION objects and receives an ASSOCIATION object generated according to the updated rules in this document? In that case, if I understand this document correctly, the ASSOCIATION object will be compliant with RFC 4872; will the legacy implementation correctly process the ASSOCIATION in that case?
This seems like a clear document. And thanks for a very crisp and clear IANA section.
I have a simple editorial Discuss that is important enough to require that it is fixed before publiscation. --- Section 3 Block Length: 16 bits The length of this report block in 32-bit words, minus one. For the Packet Delay Variation Metrics block, the block length is equal to 4. Nice! The figure shows... 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=NPDV | I |pdvtyp |Rsv| block length=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I have a number of Comments that I hope you will look at before publication. --- I should have liked it if Section 1 had a small subsection giving some form of requirement. I.e., although RFC6390 gives goodguidance, for this document I would have liked to understand what it is that people intend to do with this XR block. Similarly, the applicability statement in 1.4is very open! The concern (which I doubt is valid, so this is not a Discuss) is that you are defining a protocol extension with no particular planned use, but a general statement that someone might use it. We obviously do not need to clutter our protocols with extensions that no-one actually uses. --- Do you not think that there should be some mention of Y.1541 and G.1020 in the Introduction? --- I think [MEASI] is used in a way that makes it a normative reference. --- Section 3 If the measurement interval is not received for this metric block, this metric block SHOULD be discarded. Why is that a SHOULD not a MUST? Under what circumstances MAY the metric block be retained? How would it be used? --- Section 3.2 Interval Metric flag (I): 2 bit The value I=00 is not valid? What happens if it is received? --- Section 3.2 calls the final bits "reserved" but the figure shows them as "unused"
Two nitty-nits:-) - maybe expand PDV and MAPDV on 1st use in draft. - maybe add a reference for "2-point PDV"
Minor observation: something is missing in this text from the "Document Quality" ballot text: and other new may show up. Perhaps "interoperability issues" or "conformance issues"?
In section 2, you should cite RFC 5234. The ABNF in section 4 is a mess. First, the indents are different; that's legal, but hard to read. As far as specifics: rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF Why is this not: rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF ? (defined in [RFC3611]) This line needs a ";" in front of it if it's a comment. And what is defined in 3611? I can't tell. pdvtype = "pdv=" "0" ; MAPDV2 ITU-T G.1020 / "1" ; 2-point PDV ITU-T Y.1540 / 1*2DIGIT ;Value 2~15 are valid and ;reserved for future use That just has to be wrong. This matches: pdv=0 1 5 14 It does not match: pdv=1 pdv=5 pdv=14 Without the parens, concatenation takes precedence over alternation. I think you want this: pdvtype = "pdv=" ("0" ; MAPDV2 ITU-T G.1020 / "1" ; 2-point PDV ITU-T Y.1540 / 1*2DIGIT) ;Value 2~15 are valid and ;reserved for future use That gets you the right result. nspec = "nthr=" fixpoint ; negative PDV threshold (ms) / "npc=" fixpoint ; negative PDV percentile pspec = "pthr=" fixpoint ; positive PDV threshold (ms) / "ppc=" fixpoint ; positive PDV percentile These are fine, but would be clearer with parens. DIGIT = %x30-39 This can simply be imported from RFC 5234; no need to redefine it here.
The Performance Metrics Framework [RFC6390] provides guidance on the definition and specification of performance metrics. The RTP Monitoring Architectures [MONARCH] provides guideline for reporting block format using RTCP XR. The XR Block described in this document are in accordance with the guidelines in [RFC6390] and [MONARCH]. "in accordance with RFC6390": Are you defining the metric according http://tools.ietf.org/html/rfc6390#section-5.4.4? I don't think that's correct! I see that you referenced [G.1020] and [Y.1540], and that's fine. However, there are some other aspects of http://tools.ietf.org/html/rfc6390#section-5.4.4, specific to RTP, that should be filled in. For example: Measurement Point(s) with Potential Measurement Domain, Measurement Timing, etc.. My entire point is more a DISCUSS-DISCUSS, for both draft-ietf-avtcore-monarch-19 and draft-ietf-xrblock-rtcp-xr-pdv-05.txt. Sorry to pick on these two drafts, but we need to have an IESG performance metrics discussion. Where does the list of performance metric definitions come from at the IETF? We have multiple sources: - IPPM for IP performance metrics - RTCP for RTP performance metrics: Definitions in the document themselves or potentially referencing some other SDOs Example: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-05 bits 014-011 0: MAPDV2, Clause 184.108.40.206 of [G.1020], 1: 2-point PDV, Clause 6.2.4 of [Y.1540]. - PMOL: Performance Metrics at Other Layers, with RFC 6076 on Basic Telephony SIP End-to-End Performance Metrics - IPFIX will one day or the other exports performance metrics. I see for example http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-ipfix-03 It's again a redefinition, and it should not be! My concerns are that we start to define performance metrics in different parts of the IETF, without consistency. We have defined RFC 6390 on "Guidelines for Considering New Performance Metric Development", which ask for specific definition See http://tools.ietf.org/html/rfc6390#section-5.4.4 I believe that the IETF should at least: - define the performance metrics in a consistent way according to RFC6390. - document those performance metrics in a single location So my questions are: - are we defining the performance metrics the right way? - where is this shared repository of performance metrics (at least for the ones created in the IETF)? - is the PMOL directorate (RFC 6390) used effectively?
Just one non-blocking comment on the abstract: The abstract should be readable on its own by someone who doesn't know what RFC XYZ is about and sees only the title and abstract. Someone who doesn't know what RTP and RTCP are won't get any clue from the abstract. Will you consider this, so people will immediately see what the document refers to?: OLD This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. NEW This document defines a Real-Time Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of Packet Delay Variation metrics for a range of Real-time Transport Protocol (RTP) applications. --- Also, I will note that the shepherd writeup is incorrect: > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. > > N/A Section 5.4 creates a new registry with Specification Required policy, which requires the appointment of a designated expert. I presume the ADs have or will get the input they need to appoint one, but I wanted to point out the need, since the shepherd writeup didn't.
Documents like this would benefit from a worked example showing a set of RTP packets as seen by the element doing the metric calculation, demonstrating where the inputs to the calculation come from. Please consider such a section for future documents of this type. Should the Y.1540 reference be updated to the currently in force version (Mar2011)?
1) s1.2: Is this a "MUST": r/This draft defines a new Extended Report block that must be used in accordance with [RFC3550] and [RFC3611]. /This draft defines a new Extended Report block for use with [RFC3550] and [RFC3611]. 2) s3.2, Packet Delay Variation Metric Type: Trying to figure out whether there some other way to interpret an enumerated ;) Maybe just replace should be/is: r/Packet Delay Variation Metric Type is of type enumerated and should be interpreted as Integer. /Packet Delay Variation Metric Type is of type enumerated and is interpreted as Integer. 3) s3.2: Reserved: Curious why there's a SHOULD where almost every other time I can remember it's a MUST for setting reserved bits to zero: In the absence of such a definition, the bits in this field SHOULD be set to zero and MUST be ignored by the receiver. 4) s3.2: Positive PDV Threshold/Peak (and others): Is the S11:4 format documented somewhere?
Thanks for quickly addressing my DISCUSS
This represents an update to the error handling procedures given in [RFC4271] Sections 6.2 and 6.3 by specifying the behavior in the presence of AS0. Thanks for this clear statement in the Introduction. I wish all "updates" documents did that.
The authors report than changes are pending to handle the editorial comments raised in the Gen-ART Review by Meral Shirazipour on 23-Aug-2012. I hope the updated I-D will be posted prior to IESG approval of this document.
I support Martin's DISCUSS. I don't have any technical issue with this document; it will basically work. However, it does seem to be quite a bit of a Rube Goldberg solution, in that it's significantly more error-prone, less efficient, and more complex than simply having the loopback node compute and send the desired statistics back to the source. I may be missing something huge about the motivations that's not stated clearly in the document though.
I reckon this ought be an easy one to resolve. If the loopback media and the "forward" media can ever have different security protection applied then that would create potential vulnerabilities. I think that you need to say that the same protection SHOULD or MUST be applied to both. The only reason I can think of for a SHOULD would be if you want to use this feature to test if your crypto stuff is the source of problems. Note: I'm not arguing that you SHOULD or MUST apply any particular security, but that if you do, you need to do the same to both streams.
The overall document is fine, but Section 10 about Congestion Control hit my eyes. Section 10 says that the mirror should not perform congestion control and puts the burden for the forward and backward direction to the loopback source. At least in the second paragraph. How does the loopback source know about congestion on the path from the mirror to the source? The text does not say anything about it and I have trouble to see how the source can fully infer what the congestion status on the forward direction to the mirror and also on the way back is. Further, the first paragraph and the second paragraph are contradicting each other, as the first one says that all participants SHOULD implement congestion control, but the second says that the source SHOULD, but not the mirror. I would be fine if any, i.e., source and mirror, are bound to "SHOULD implement congestion control". This will increase the implementation effort on the mirror, but the mechanisms are anyhow there, if the loopback source is implementing it.
[The below are mostly 2119 problems. I normally would make this a Comment and simply ballot "No Objection", but there are so many of them, and their use is in ways that I think could complicate or confuse an implementation, that I'd like to "Discuss" for a bit. If the AD thinks these are best handled as a comment, I will happily change my ballot. If the AD would like me to help make all of these changes, I will leave it as a "Discuss" and discuss the changes with the authors/WG.] Overall comment: This document uses the phrase "compliant to this specification" in several places, normally followed by some 2119 keyword. These uses are unnecessary, redundant, and mostly incorrect. To say, "An SDP offerer compliant to this specification MUST do X" is exactly the same as "An SDP offerer MUST do X." And in most cases, "MUST do X" is also wrong; normally, you really mean "will do X". Again, in most cases, you are defining the semantics of the protocol, not stating a protocol requirement that implementations need to be wary of. This document could use a serious scrubbing of these terms. There are some specifics below (and I certainly haven't covered all of them; I stopped looking after section 6), as well as some other comments. 3.1: An SDP offerer compliant to this specification and attempting to establish a media session with media loopback MUST include "loopback" media attributes for each individual media description in the offer message. The offerer MUST look for the "loopback" media attributes in the media description(s) of the response from the answer for confirmation that the request is accepted. The first sentence is a definition, not a protocol requirement. In the second sentence, the requirement to "look" is silly. Looking can't possibly be the requirement; nothing bad will happen if I don't look. Instead: An SDP offerer implementing media loopback includes "loopback" media attributes for each media description in the offer message. If the request is accepted, the response from answer will have "loopback" media attributes in the media description(s). A similar rewrite should be done to the first paragraph of 3.2. In the second paragraph of 3.2, you can change "MUST be" to "is". 4.1: I would change "MUST be used" to "are used" 4.2 and 5.1 paragraph 1: I'm pretty sure "MUST include" could just be "includes" 5.1: "MUST be used" -> "is used" 5.2, paragraph 1: "MUST follow" -> "will follow". I'd also like to see "and hence MUST NOT be used" just deleted; it doesn't add anything as far as I can tell. If an answerer wishes to accept the loopback request it MUST include both the loopback role and loopback type attributes in the answer. Instead: An answerer includes both the loopback role and loopback type attributes in the answer to indicate that it will accept loopback requests. Also: "MUST be loopback-mirror" -> "will be loopback-mirror" 5.5: This entire section should be removed; it is not important to this particular document as it is a general problem for any protocol. Furthermore, if the mirroring entity is behind a NAT, it MUST send some packets to the identified address/port(s) of the peer, in order to open the NAT pinhole. That MUST is completely bogus. Even if being behind a NAT always required sending packets to pinhole, the MUST is still wrong: This is not a requirement of *this* protocol; it's just stating a fact. But the fact is that being behind a NAT does *not* require pinholing: If the entity is behind a PCP server, it MUST do no such thing. Note that for any form of NAT traversal to function, symmetric RTP/RTCP [RFC4961] MUST be used. In other words both agents MUST send packets from the source address and port they receive packets on. Again, completely false in the case of PCP. Please remove section 5.5. 6: A loopback mirror that is compliant to this specification and accepts media with rtp-pkt-loopback loopback type MUST loopback the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in Section 7 of this specification. What else might a loopback mirror try to do that this paragraph is trying to prevent? "MUST transmit all received media" -> "will transmit all received media" "incoming media MUST be treated" -> "incoming media will be treated" 13: All implementations MUST at least support the rtp-pkt-loopback mode for loopback-type, with direct media loopback payload encoding. I don't understand: Are you saying that there is no environment under which I might *only* implement rtp-media-loopback? Why is this a MUST?
I agree with Wes's comment; perhaps the Rube Goldberg aspect comes in part from the long gestation period of the document (eight years in the making), which tends to cause a lot of accumulation. Please consider changing the title of Section 13 to "Applicability Statement" (from "Implementation Considerations"), because I believe that's what that section is (see RFC 2026, Section 3.2, end of the second paragraph).
Consider expanding the description of the attack and the defense against the attack in the second paragraph of the security considerations section. Authentication of the signalling does not prevent the attack - it just provides a way to identify the bad actor. It should also be clearer that this takes a 3pcc style call setup. Consider also suggesting that implementations terminate loopback streams that are sending packets at rates that are significantly greater than what the expected rate for what's being carried.
Security considerations: if the EL value is calculated only based on packet headers then a relatively efficient wiretapping interface could be added depending on the function used to generate the EL value. If a network didn't want that to be possible or too easy then it could add some other input to the generation of the EL values that'd make it harder to build a table of EL values to tap given knowledge of the keys from the packet. For example the ingress LSR could generate a random input to the EL generation process every so often. I've no idea if that's practical nor worth inclusion but thought I'd mention it anyway just in case.
I am voting Yes on this useful and mainly well written document, however I do have some comments that I would request that the authors and responsible AD consider. In section 4.1 "If an ingress X chooses" I think that is an ingress LSR (although you define it later this is the first time we meet "X") ==== "This is to avoid jitter, latency and re-ordering issues for the flow." Re-order for sure, but I don't see how jitter and latency come into play. ======= "1. at the ingress LSR, MPLS encapsulation hasn't yet occurred, so deep inspection is not necessary;" Some people would consider a network layer device looking at the transport headers to do ECMP as a DPI. ======= "On the other hand, an ingress LSR (e.g., a PE router) has detailed knowledge of an packet's contents, typically through a priori configuration of the encapsulation(s) that are expected at a given PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They also have more flexible forwarding hardware." The last sentence is disputable because it is highly implementation dependent. There are ASIC and even Network Processor based PEs that will not be able to push as the extra labels. I would delete the last sentence. ======= 3. Entropy Labels and Their Structure Entropy labels are generated by an ingress LSR, based entirely on load balancing information. However, they MUST NOT have values in the reserved label space (0-15) [IANA MPLS Label Values]. Did I miss this reference to [IANA MPLS Label Values]? ======= "for multicast LSPs will be specified in a companion document." Companion or future? I don't think it is yet a WG draft ======= Section 8.1, 8.2 and 8.3 are quite hard to follow. They are only informational, so it would probably be better if they were in an appendix, so that any errors will not impact the protocol definition. It would also really help the reader if some text were provided in each case explaining what is happening. Once the first example has been explained in detail, many of the others just need text describing the delta.
Just one minor comment. in section 2. "Scenarios Involving Mailing Lists" Generally (and exclusively within the scope of this document), an original message is sent to a mailing list as a completely separate and independent transaction from the list agent sending the retransmitted message to one or more list recipients. In both cases, the message might be addressed only to the list address, Not sure what "in both cases" refer to?
The authors report than changes are pending to handle the editorial comments raised in the Gen-ART Review by Meral Shirazipour on 31-Jul-2012. I hope the updated I-D will be posted prior to IESG approval of this document.
Saying "encryption of the monitoring report is recommended" seems a bit trite. I'm not asking that you define precisely how to secure all possible RTP deployment choices, but perhaps the right thing to do here is to say that these metrics SHOULD be secured to the same extent as the RTP flows that they measure. (Or some such.) How could you encrypt traffic for a 3rd party monitor without knowing who that monitor is? That seems somewhat impossible in general. So, as pointed out by the secdir review  the document should at least recognise the problem and maybe describe some environments where it can in fact be solved.  http://www.ietf.org/mail-archive/web/secdir/current/msg03465.html
1. I'm confused by the scope of this document The title says: Guidelines for Use of the RTP Monitoring Framework The abstract says: This memo proposes an extensible RTP monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. The introduction says: The objective of this document is to describe an extensible RTP monitoring framework to provide a small number of re-usable Quality of Service (QoS) / QoE metrics which facilitate reduced implementation costs and help maximize inter-operability. So is it both about new metric definitions AND guidelines how to encode them? It seems the focus is on the second part only. In such a guidelines document, I was expecting a few words about the new metrics: definitions, existing registry, reusing definitions, etc... Then, I was then expecting this document to refer to RFC 6390. Something similar to the http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-qoe-02 section 1.3, which mentions: 1.3. Performance Metrics Framework The Performance Metrics Framework [RFC6390] provides guidance on the definition and specification of performance metrics. Metrics described in this draft either reference external definitions or define metrics generally in accordance with the guidelines in [RFC6390]. But, even with a stronger statement: "must follow RFC6390" Also, I believe that some aspects of the document should really be based on RFC6390. For example, "Composed metrics" is really the PMOL "Composed Performance Metrics" "interval metrics" is the PMOL "Measurement Timing". If the "interval metrics" and "composed metrics" are not defined in one of the RTCP document, I'd suggest using the PMOL term. Idem for "sampled metrics", which should be based on the PMOL "Measurement Timing" 2. I believe the relationship with RFC 5968 is not clear. Does this document contain a superset of the guidelines in RFC 5968, specifically regarding monitor? I believe a clear statement is required. Something such as "all the guidelines from RFC 5968 must apply on top of the guidelines in this document" 3. Actually, my entire point is more a DISCUSS-DISCUSS, for both this draft and draft-ietf-xrblock-rtcp-xr-pdv-05.txt. Sorry to pick on these two drafts, but we need to have an IESG performance metrics discussion. Where does the list of performance metric definitions come from at the IETF? We have multiple sources: - IPPM for IP performance metrics - RTCP for RTP performance metrics: Definitions in the document themselves or potentially referencing some other SDOs Example: http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-05 bits 014-011 0: MAPDV2, Clause 220.127.116.11 of [G.1020], 1: 2-point PDV, Clause 6.2.4 of [Y.1540]. - PMOL: Performance Metrics at Other Layers, with RFC 6076 on Basic Telephony SIP End-to-End Performance Metrics - IPFIX will one day or the other exports performance metrics. I see for example http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-ipfix-03 It's again a redefinition, and it should not be! My concerns are that we start to define performance metrics in different parts of the IETF, without consistency. We have defined RFC 6390 on "Guidelines for Considering New Performance Metric Development", which ask for specific definition See http://tools.ietf.org/html/rfc6390#section-5.4.4 I believe that the IETF should at least: - define the performance metrics in a consistent way according to RFC6390. - document those performance metrics in a single location So my questions are: - are we defining the performance metrics the right way within the IETF? - where is this shared repository of performance metrics (at least for the ones created in the IETF)? - is the PMOL directorate (RFC 6390) used effectively?
- OLD: There are many ways in which the performance of an RTP session can be monitored. These include RTP-based mechanisms such as the RTP SNMP MIB [RFC2959], or the Session Initiation Protocol (SIP) event package for RTCP summary reports [RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow, IPFix, and so on. NEW: There are many ways in which the performance of an RTP session can be monitored. These include RTP-based mechanisms such as the RTP MIB module [RFC2959], or the Session Initiation Protocol (SIP) event package for RTCP summary reports [RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow [RFC3954], IPFIX [RFC5101] [RFC5102], and so on. - Not sure why you rename the Monitor [RFC3550] to RTP Monitor. I search for RTP Monitor in RFC 3550 and could not find it, obviously! - Add an extra comma after "on reception quality" in the following text Both the RTCP or RTCP XR can be extended to transport these metrics, e.g., the basic RTCP Reception Report (RR) [RFC3550] that conveys reception statistics (i.e., transport level statistics) for multiple RTP media streams, the RTCP XRs [RFC3611] that supplement the existing RTCP packets and provide more detailed feedback on reception quality and RTCP NACK [RFC4585] that provides feedback on the RTP sequence numbers for a subset of the lost packets or all the currently lost packets. - Somewhere in the section 6, I would refer to RFC 5481 for PDV/IPDV. Al Morton and I created that RFC as they were much confusion about PDV/IPDV and because some different terms were used. For example, see RFC 5481 section 1. There are many ways to formulate packet delay variation metrics for the Internet and other packet-based networks. The IETF itself has several specifications for delay variation [RFC3393], sometimes called jitter [RFC3550] or even inter-arrival jitter [RFC3550], and these have achieved wide adoption. ... That would be ideal (up to you) if the draft would use: delay variation instead of jitter. See some justifications in Section 1 of RFC 5481. - Minor comment: take it or leave it. Slightly confusing sentences containing QoE, as QoE is at the same time a acronym and a reference "that can be used to correlate the metrics, provide end to end service visibility and measure and monitor Quality of Experience (QoE) [RFC6390]." "One example of such metrics is the QoE Metric specified in QoE metric reporting Block [QOE]." Proposal OLD: "One example of such metrics is the QoE Metric specified in QoE metric reporting Block [QOE]." NEW: "One example of such metrics is the QoE Metric specified in QoE metric reporting Block [QOE_BLOCK]."
Please consider expanding "RTP" in the first line of the Abstract.
TED is used before being defined (on p11)
I have no problems with the publication of this document and only have the following comment. - The discussion of objective functions seems incomplete. Section 4.1 talks about deriving an optimal end-to-end path based on an OF or set of OFs. However, in talking with one of the authors, it became clear that the same OF (or set of OFs) may not be applied across all domains given local policy within a domain and/or contractual arrangements between domains. I think it would be useful to add some discussion of these types of issues and the impact they will have on the optimality of the computed path.
I support the publication of this draft. Adding federated authentication to IPP [RFC3229] (and other relevant protocols) would enable this kind of remote printing service without the administrative overhead of credentialing these visitors (who, of course, may well one time visitors to the organisation). Are you sure it's the right RFC? Regarding the next two comments, take them or leave them, up to the WG authors/chairs/AD 1. There are multiple sentences that speak about the ABFAB architecture and specifications. - The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. - This document enumerates some of these use cases, describing how technologies based on the the ABFAB architecture [I-D.lear-abfab-arch] and specifications could be used. - This document enumerates some of these use cases, describing how technologies based on the the ABFAB architecture [I-D.lear-abfab-arch] and specifications could be used. - ABFAB could help in this context as its specifications would enable federated authentication for a variety of non-web protocols, ... - The use of ABFAB technologies in this case would enable both the front or back end attribute exchange required to provide subject attributes. - etc... You chose to have a use cases RFC before the architecture RFC. That's your choice, and that's fine! However, it would be nice to explain in one paragraph (potentially with a figure) how you envision the architecture: organization A, organization B, a user who authenticates in the org A and needs to access the information in org B a RADIUS connection from org. A to org B. with SAML content within the RADIUS data. I had to dig outside of the draft to find this information, but it helped me tremendously to start to understand the technology challenges behind the use cases. In 5 years from now, which RFC should a new newcomer read first to start understanding what the WG does? Is it this one or the architecture? 2. A sentence or two regarding the relationship with the ABFAB and SCIM use cases (in this document or in a different subsequent document, not sure) As far as I can tell: SCIM: pre-provisioning identity management across domains ABFAB: Single Sign On across domains
Nit: -- Section 3.1 -- Lots of editorial stuff, but it'll all be sorted by the RFC Editor. One nit that might not be is this one: o Common application software such as email, shared storage, business applications such as Customer Relationship Management (CRM) or scientific applications ("Software as a Service", or Saas). The last letter of "SaaS" needs to be capitalized.
In section 3 maybe we could remove the marketing paragraph because it's not really relevant why somebody might use the cloud - the fact is they do so this is not needed: The main benefits of cloud computing are that it offers on-demand services with pay per-use removing the need for users/organizations to build and maintain their own hardware or infrastructure, and that it allows for the dynamic scaling of resources required for solving specific tasks.
I am retaining my Yes ballot, and I thank the authors for addressing my Comments entered against revision 05. It continues to be my opinion that, in stating an important point about the use of these tests on live, and dynamically routed, shared-resource IP/MPLS networks, the document overstates its case an implies that the use on network paths in dedicated-resource networks (such as MPLS-TE or MPLS-TP) is harmful when it is neither obvious nor proven that this is the case. In this, I agree with Stewart's Discuss and wish that the authors would make a clearer and more upfront statement about the scope of the network in which this may be harmful. The solution to this may be as simple as a change to the title to something like: Use of RFC 2544 Benchmarking Test Methodologies on Production Networks with Shared Resources Considered Harmful In making this change you would not be commenting about TE or transport networks, but would be making the clear statement about where you know the harm to be. --- New typo introduced... Section 4.2 In other words, devices operating on the Internet may be configured to discard any traffic they observe in this address range, as it is intended for laboratory ITE use only. Thus, testers using the assigned testing address ranges are connected to the Internet and test packets are forwarded across the Internet, it is likely that the packets will be discarded and the test will not work. s/Thus, testers/Thus, if testers/
- section 1: "unintended specifications" sound quite odd, I think you could usefully re-phrase that.
If anything needs an "Updates:" header, it seems to me this document does. Is there a reason you have not put in an "Updates: 2544"? (I wish 2544 were standards track. I wish this one were as well. Sailed ships I expect. No action needed; I'll just go weep in my beer.) Section 1: To directly address this situation, the past and present Chairs of the IETF Benchmarking Methodology Working Group (BMWG) have prepared this Applicability Statement for RFC 2544. The mention of the past and present Chairs seems a bit self-aggrandizing. Could you simply say: "This Applicability Statement for RFC 2544 (or even just "This document") directly addresses this situation."
To directly address this situation, the past and present Chairs of the IETF Benchmarking Methodology Working Group (BMWG) have prepared this Applicability Statement for RFC 2544. I'm going to push this also, where Pete gave it up... though it's still non-blocking. I very strongly ask you to change this. (1) Working group documents are the products of working groups, not of individuals. (2) Statements like this imply that people in positions of leadership rammed something through, forcing "consensus" with a bulldozer. (3) At best, statements like this appear to be appeal-to-authority arguments. We should avoid that when it's not necessary, and I don't see that it's necessary here. If BMWG has strong consensus on what this document says, then say *that*. That statement means more to me than one that says that four chairs thought it was important. (I'll also note that when you couple that statement with the Acknowledgments section, which recognizes five people and doesn't mention the working group, one *could* take away from this that there were nine people who read and agreed with this. Saying instead -- explicitly, rather than the usual implicit message we give -- that this represents *strong* consensus of the BMWG makes it very clear.) Apart from that, I'll let Stewart and Adrian sort out whether or not you're overstating anything.
The steps that I agreed with the sponsoring Area Director to resolve my Discuss were that the comments posted by Adrian would be included and I would then re-review the draft to see it it addressed my concerns. I note that a number of Adrian's comments have not been included in version 6 of the draft. I would additionally like to propose two changes to the draft that I think would address the fundamental basis of the my concerns, and if these are acceptable to the authors I will review the updated text with a view to clearing my discuss. I think one of the following document titles would be more appropriate: a) RFC 2544 Applicability Statement: Use on Production Networks Employing Contended Resources Considered Harmful or b) RFC 2544 Applicability Statement: Describing When Used on Production Networks Can be Considered Harmful My preference is for (a), but I can accept (b). Then in the Abstract and Introduction there needs to be some scoping text that describes the network situation considered by the authors. This document is scoped to the case where the production network provides a service using contended resources. Production networks using un-contended resources are out of scope.
This paragraph: > > MPTCP's interpretation of, and effect on, regular single-path TCP > semantics are discussed in Section 4. > seems to be out of place in the Terminology section.
I have several Comments that don't really merit a Discuss, but which you should really think about a little. --- The description of Figure 13 could be clearer about the meaning of the value n. I.e., there are n Address IDs present. You should probably say whether n=0 is allowed. Lastly, you should mark the unused bits on the figure as reserved. --- In Figure 17, shouldn't the transition out of M_LAST-ACK (right-hand side) be into M_TIME WAIT? Otherwise, the MPTCP PCB seems to not get deleted. --- Are you really happy with "RFC Required" as the allocation policy for the new MPTCP Option Subtypes registry? You understand that one person could write an Independent Stream RFC and take all of the available code points in one go? Although you might hope that the IESG would spot this and request the ISE to not publish the RFC, this seems like a risk. Since the plan is to move to the Standards Track, why don't you change this to "Standards Action"?
1. Separate from the details below, if MPTCP is a success then it will be used for many years. However, the approach taken seems to be limited to only ever supporting weak security due to TCP option size restrictions and the fact that you don't amortize any crypto parameters over more than one packet. Attacker-capabilities will increase with Moore's law so that just seems to be an insecure design choice at quite a high level. Can you tell me either how you could practically extend this design for stronger cryptographic security or else why its ok for that to be practically impossible? TCP-MD5 should be a salutory lesson here really. 2. Sending 64 bit keys in clear over the network with a negotiation scheme that only allows 7 algorithms ever and with sha-1 hard coded in various places == DISCUSS. I assume you anticipated this discuss;-) Probably the best place to start is if you can send me a link to where this cryptographic scheme was discussed in the wg archive, in case questions I'd ask were already discussed. I have many questions: for example, if a TCP option can handle 128 bits then why not use 128 bit keys in SYN and SYN/ACK and just put the tokens in the ACK? Why not use some form of Diffie-Hellman? Why hard-code sha-1 for token and IDSN generation? Why has ADD_ADDR no MAC? etc etc. (Note; If we can sort point 1 this one will become much easier, since the current experimental spec could then be replaced with a better-security variant.) 3. What is the actual probability of a token collision in 3.1? I'm concerned it is not "very small" and most especially for a server with many connections. Have you done the math on this? According to  the probability is about 10% of there being one collision with 25k connections and hits 50% with 77163 connections. That is not really "very small." And that ignores implemention and/or RNG problems which are arguably more important. The DISCUSS is: what are the consequences of a substantially higher probability of token collisions for MPTCP? (And why not at least add some bits to that token?)  http://preshing.com/20110504/hash-collision-probabilities 3. Don't you need to say that a host MUST drop the connection if it had set C=1 but receives a packet with a missing checksum?
- 1.1: surely the WG and not the authors imposed the design constraints? If not, why not? - 1.3: "Path" isn't an "MPTCP-specific term" its a term used with a specific meaning by MPTCP. Same for others. - 2.2: I hope those keys are what I think they are. What is MAC'd? - 3: Just wondering. (And probably showing my ignorance;-) Does that duplicate ACK interact in any way with conex or ECN? - 3.1: RFC 4086 gives recommendations for generating random numbers, not random keys. - 3.1: The key does not only have local meaning if its used in two places, which it is. - 3.2: Why has the attacker only one chance to guess the MAC? I'm not sure that's true. - Section 5: the "no worse" security requirement didn't work out so well before, e.g. for WEP. - Acks: I'd suggest you remove the EU liability disclaimer since I'd not like to see that become common and I don't think its really appropriate.
As Pete noted: The shepherd write-up is broken with respect to point (7). This should have been confirmed before submitting the draft to the IESG. A comment where your response is requested: Section 30, paragraph 6: > The value 0xf is reserved for Private Use. What is private use in your definition? In your testbed only or for your own protocol extension used on the public Internet? The first definition is Ok, with second some folks might step on other folks toes when running their code across the Internet at the same time. Three comments for your considerations, but no need to respond to these: Section 3.4.2., paragraph 3: > For security purposes, if a host receives a REMOVE_ADDR option, it > must ensure the affected path(s) are no longer in use before it > instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger > the sending of a TCP Keepalive  on the path, and if a response is > received the path SHOULD NOT be removed. Typical TCP validity tests > on the subflow (e.g. ensuring sequence and ack numbers are correct) > MUST also be undertaken. Should such an event be logged? Looks like that something is going wrong. Section 3.5., paragraph 9: > o If host A does not receive a TCP RST in reply to its MP_FASTCLOSE > after one RTO (the RTO of the subflow where the MPTCP_RST has been > sent), it SHOULD retransmit the MP_FASTCLOSE. The number of > retransmissions SHOULD be limited to avoid this connection from > being retained for a long time, but this limit is implementation- > specific. For the sake of the implementers: What is the guidance here on retransmissions? Section 6., paragraph 15: > o Traffic Normalizers  may not allow holes in sequence numbers, > and may cache packets and retransmit the same data. MPTCP looks > like standard TCP on the wire, and will not retransmit different > data on the same subflow sequence number. In the event of a > retransmission, he same data will be retransmitted on the original > TCP subflow even if it is additionally retransmitted at the s/he same data/the same data/
This appears to me to be great work, and as an applications guy, I cannot wait for this to be deployed. The only thing that prevented me from balloting "Yes" instead of "No objection" is simply because much of the detailed technical work is beyond my knowledge base and I can't vouch for it personally. But what I do understand I'm very pleased by. One addition that might serve folks well: You might add a section at the beginning or end of the document on open experimental issues that need to be addressed before going to standards track. In particular, 3.3.6, 3.3.7, and 3.8.2 point out such issues. I'm sure there are more. If you could summarize them in one section, it might be helpful.
IANA had questions about the "MPTCP cryptographic handshake algorithms" registry that the authors did not answer, and which need to be answered. I also have a question about it. The IANA Considerations say this: This document also requests that IANA keeps a registry of "MPTCP cryptographic handshake algorithms" based on the flags in MP_CAPABLE (Section 3.1). ... Note that the length of this field is not fixed; it is a definition of the meaning of each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10, etc). Future specifications may define additional flags using the leftmost bits of this field, and therefore the number of bits available for cryptographic negotiation may change. IANA's question, sent on 14 August, is this: Questions: Does this registry have a maximum value? And if so, what is it? Should value 0x0 be marked as 'Reserved'? Part of the answer to the question is, of course, to explain bit fields: 0x0 is invalid, but also things like 0x3, 0x5, and 0x6 will not be registered at all, because they're combinations of bits. Perhaps the document would be clearer to IANA if it referred to bits, perhaps this way: +-----------+----------------+----------------------------+ | Flags | Algorithm Name | Reference | +-----------+----------------+----------------------------+ | 0000001 | HMAC-SHA1 | This document, Section 3.2 | +-----------+----------------+----------------------------+ On the other hand, the notation you're using is understandable to us, so perhaps IANA doesn't need to understand it. But the other part of the question, and the one I have a question about as well, is what it means to say that the length is not fixed. It appears to be fixed at seven bits, of which one is already allocated. How can more than six other bits be allocated? I don't see any way to extend the bit field to create more bits. Please explain. And then please respond to IANA's message, so they can get the registry right. Also also, should this second new registry also be a sub-registry of "TCP Parameters", as the first one (MPTCP option subtype values) is? Right now, IANA plans to make it a new top-level registry.
It's easy to see that the mptcp implementation is expected to be able to send an address and optionally ports to the remote peer as part of an Add Address (3.4.1), but it's not clear whether the application gets to influence what that port is. The API document only talks about adding addresses (abstractly). Is it the intent to allow an application above the mptcp implementation to tell mptcp which local ports will work for each new interface added (which the app may have learned through interacting with a firewall control protocol for instance), and which should be used for a new subflow? If so, can the document please make it more obvious when/where this occurs? Would it be difficult to add a short summary to this document calling out what information the mptcp implementation is expecting to get from the API? Consider being more explicit about whether an mptcp connection can exist with no subflows. There is a requirement in 3.3.3 ("Essentially, a host MUST NOT close all functioning subflows unless it is safe to do so") that I think means no, but it's written in the context of closing the mtpcp connection. If an application removes all the available interfaces, should the connection continue to exist allowing a new subflow to be added later? Should the implementation return an error if the last interface for a connection is removed before closing it (or doing something else that would remove the last subflow)? Or should it complete a DATA_FIN sequence before removing the last subflow? Apologies if I missed where this is already described.
I found this a well written and clear document - thanks. Just a couple of points I'd like to discuss before changing my ballot position: 1) s3.1 contains the following: If the listener acts in this way, however, it MUST generate its key in a verifiable fashion, allowing it to verify that it generated the key when it is echoed in the ACK. What do mean by "in a verifiable fashion"? Do you really mean reproducible? 2) I'm curious if the WG discussed not reusing the key for subsequent connections to the same host? 3) s3.1: (apologies if this is somewhere that I missed) Should you explicitly state that receiving an MP_CAPABLE option in anything other than the 1st subflow is an error and the such-and-such error code should be returned? 4) s3.1: Did the WG consider adding a nonce in the MP_CAPABLE option to protect against replay? 5) s3.1/s3.2: Hate that this uses SHA-1 for the IDSN and token, but I guess you're not really worried about collision resistance. Is that true (gets a little bit at one of Stephen's)? If it's true, you need to say something about not really needing that property of the hash algorithm in the security considerations. Here's some text that's in a TLS WG draft that might be a good starting point: The hash algorithm used in this specification is required to have reasonable random properties in order to provide reasonably unique identifiers. There is no requirement that this hash algorithm must have strong collision resistance. I guess maybe just add: The hash algorithm used in this specification to generate the IDSN and token is … 6) s3.1: Instead of hardcoding the IDSN and token generation algorithm to SHA-1 could you hardcode it to whatever HMAC paired algorithm you use? That way it's kind of like a suite of algs - S=1 and SHA-1 gets used for everything IDSN, token and MAC, S=2 SHA-256 gets used in those places and so on. I'm worried that in the future folks will need to string along SHA-1 when it's good and dead and we've all moved on to SHA-* (or whatever). I can see some security auditor asking does you product use SHA-1; and I say why yes it does; and they say we can't buy your product or you fail this evaluation. 7) s3.5: Why are you returning the receiver's key in the MP_FASTCLOSE? Couldn't you send something else back? Also need to update the security considerations to mention that the receivers key is also returned in the MP_FASTCLOSE option.
0) Fully support Stephen's discusses. 1) s2: r/standard/common ? 2) s3: MUST in the following? : Those MPTCP options associated with subflow initiation must be included on packets with the SYN flag set. 3) s3.2: Probably worth adding another reference to  in the following paragraph: The MP_JOIN SYN not only sends the token (which is static for a connection) but also Random Numbers (nonces) that are used to prevent replay attacks on the authentication method. 4) The reference for SHA-1 is normally: "Secure Hash Standard", United States of American, National Institute of Science and Technology, Federal Information Processing Standard (FIPS) 180-3, http://csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf. and then you can provide an informative reference to RFC 6234 as a possible implementation. Not everybody is going to use the code in 6234. 5) s3.2: Could you just use HMAC (hash-based message authentication code) instead of MAC in the text and in the figures? I think it makes it much clearer and avoid the unnecessary indirection. a) f6: | Sender's Truncated HMAC (64 bits) | b) f7: The MAC is HMAC-SHA1 right? so shouldn't the figure be: | Sender's MAC (160 bits HAMC-SHA1) | c) f8: I'd make it clear it's HMAC: OLD: MAC-A = MAC(Key=(Key-A+Key-B), Msg=(R-A+R-B)) MAC-B = MAC(Key=(Key-B+Key-A), Msg=(R-B+R-A)) NEW: add H MAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B)) MAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))
This Comment is provided for consideration by the ISE and author. --- It would be helpful if the Abstract, as well as noting that the experiment was run in the 90s, also noted the how/why of this being a historic record, not an on-going experiment. Stating this in terms of the purpose of the document (as the last paragraph of Section 1) might be a good way to do it.
Thanks to Sean for unearthing the cause of the DNP and putting my concerns to rest.