IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-10-01. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Barry
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
2.3 Status changes
2.3.1 New items
2.3.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 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1106 EDT no break
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. Working Group News
1206 EDT scribe left the call
(at 2015-10-01 06:09:49 PDT)
1) In Sec 2 above Figure 1 "1) Note that throughout the document, routable address means that it is possible to route an IP packet to this address using the normal information exchanged by the IGP operating in the AS." Shouldn't that be "by the IGP and BGP (or EGP) operating in the AS"??
- 3.2: The description of the destination address offset isn't clear to me. If this is some common thing in MPLS though, that's fine. If not, maybe it'd be worth being clearer here. (It does become clear later though, so this is a nit.)
I have some comments/questions: 1. TBD2 is the Relay Node Address Stack TLV Type. There seems to be some confusion in the text: Section 4.2. (Receiving an Echo Request) says that the "Type of the Relay Node Address Stack TLV is chosen from the range 32768 to 49161…” giving the impression that any value can be used, while 8.2. (New TLV) in the IANA Considerations says that a "suggested value should be assigned” giving me the impression that the assignment is just a suggestion (and somehow reinforcing the text in 4.2), but the original definition in 3.2. (Relay Node Address Stack) simply says that the "value should be assigned by IANA”. Assuming that you simply want an assignment and that it would be what is used, please clean the text up; I suggest just referring to the value as TBD2 (in 4.2 and 8.2) and explicitly including the text about the assignment and the range (from 3.2) in 8.2. 2. Section 4.1. (Sending an Echo Request) says that the "Relay Node Address Stack TLV MUST be carried in the Echo Request message if the relay functionality is required”. How does the initiator know that it needs the functionality? 3. Section 4.2. (Receiving an Echo Request) "A second or more address entries MAY also be added if necessary, depending on implementation.” Isn’t this document defining how the implementation should work? What are the cases where these additional entries may be added?
Thanks for your work on this draft. The security review from 6 months ago hasn't been fully addressed in the draft and I think it would be helpful to do so. There were responses given on list, but corresponding updates didn't happen for all of the comments. https://www.ietf.org/mail-archive/web/secdir/current/msg05301.html For the first comment, the response was that this mechanism does not deprecate use of "Echo Reply". The language in the first paragraph of section 3 should be made clear on that point. For the second comment: s4.1: Is the outermost label allowed to be set to 255 to support the “ping” mode or must it always be set to 1, 2, etc. to support “traceroute" mode - as described in RFC 4379 s4.3? I know s5 is just an example but it really looks like this extension is just supposed to be for fault isolation. The response via email says it is possible to set it to 255, could this be made clear in the draft? The third comment was addressed, thank you. It was also good to see the security considerations cover path discovery as well as DoS related attacks. Thanks for that!
- 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what if 802.1q is fixed/improved e.g. to use sha256?
Please see the nits found in the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06068.html
1) Bottom of page 7: Please describe the meaning of the length field in the TLV and whether there is any padding. Alternately (or as well) - give a reference that defines these details.
typo? "the reverse the reverse LSP"
I support the publication, but I would like to see the update to RFC7110 clearly indicated — specially because the change modifies a “MUST” behavior. Section 3.1. (Reply via Specified Path Update) says that the "usage of the "Reply via Specified Path (5)" without inclusion of a "Reply Path TLV" is no longer invalid” — but "Reply via Specified Path (5)” (that specific string of text) doesn’t show up in RFC7110, nor does the word invalid. In digging a little bit, I can see that Section 5.1. (Sending an Echo Request) of RFC7110 says: “When sending an echo request…the Reply Mode of the echo request MUST be set to "Reply via Specified Path", and a Reply Path TLV MUST be carried…” In the end, I’m assuming that the update to RFC7110 is to change that text in 5.1 to something like “…the TLV SHOULD be carried; if it isn’t then it indicates the reverse LSP…”. Please be clear.
The security considerations say "no further considerations required" without further explanation. While I don't doubt that is true (except for those mentioned in Kathleen's DISCUSS), it would be helpful to mention the new protocol elements and procedures added, and why the wg believes they don't add any considerations beyond those in the referenced drafts.
This should be easy to resolve. SInce this draft adds a new capability to include the return path, this provides another attack vector to observe path information that could be part of reconnaissance gathering to later attack the network or path. While the referenced RFC4379 mentions the following in the security considerations section: The third is an unauthorized source using an LSP ping to obtain information about the network. The equivalent should be added for this new capability in this draft, since now it's possible to gather the path information from the new feature.
- 3.1.2: The tzdist protocol says clients SHOULD use TLS. A question then is ought servers here (be able to) include trust point information for tzdist for the service in question when they tell a client to use a particular tzdist service? - Given the three points below, maybe it is worth specifying some 'background' kind of traffic to be sent between client and tzdist services? What do you think? - section 4, point 5: that seems onerous - is a client supposed to retrieve all known timezones from all servers? What if/when those change? - section 8: missing privacy issue: if I create an event using a weird TZ and can see who accesses the tzdist service, then I can find out who is subscribed to some calendars maybe. Worth noting? I don't see what can be done about it, except maybe to ask clients to occasionally make a random query to the tzdist service just to confuse matters, but that'd also have downsides if not done well. - section 8: missing security issue: if a lot of clients are fetching this information from a tzdist server, then that becomes an interesting thing to attack as the consequences could be significant. Maybe worth noting just to encourage folks to (document their code so as to get others to) think about this when deploying.
Abstract: Is this an extension of 4791, or an update? The abstract says "extends", but the draft has an "Updates:" header. (I suspect from some of the behavior, this truly is an update.) Should the titles of 3.1.5 and 3.1.6 say "Support _of_ Time Zone Identifiers..." The security considerations say this adds no new considerations beyond those in CalDAV and iCalendar. It seems to me that adding an out-of-band mechanism to get TZ info from third parties would add some considerations. Perhaps this should reference the security and privacy considerations from ietf-tzdist-service? It's already a normative reference.
I will follow along with the discussion around Stephen's comments, I don't have any others to add for security.
Note the discussion in the shepherd writeup about the default value for "CalDAV-Timezones". The document specifies the working group's clear consensus to use a default that changes current behaviour.
Is the last sentence in this paragraph truncated? 3. Clients can expect servers not to include standard time zone definitions in any iCalendar data they receive from the server, if there is no "CalDAV-Timezones" request header field in the HTTP request. Clients MUST retrieve standard time zone definitions from the set of time zone distribution servers advertised by the CalDAV server (see Section 3.1.2), or a known.
I really like this document. I wish more working groups produced similar guidance. I did have a number of questions, that you might want to take a look at before the document is approved. This text UDP is mainly used to carry CoAP messages but other transports can be utilized, such as SMS Appendix A or TCP [I-D.tschofenig-core-coap-tcp-tls]. is somewhat ambiguous - is this supposed to say that "Most CoAP messages are carried in UDP, but other transports can be utilized, such as ..."? This document is pretty reference-rich, but For use with this profile the PSK identities SHOULD NOT assume a structured format (such as domain names, Distinguished Names, or IP addresses) and a constant time bit-by-bit comparison operation MUST be used by the server for any operation related to the PSK identity. doesn't have a reference or a definition for "constant time bit-by-bit comparison operation". Could you provide one? I wasn't quite sure what TLS/DTLS offers a lot of freedom for the use with ECC. means. At a minimum, "for the use with" needs help. I'm guessing from the rest of the paragraph that this is saying "TLS/DTLS offers a lot of choices when selecting ECC curves", or something like that. But I'm guessing. Is there a missing word in For deployments where public key cryptography is acceptable the raw public might somewhere around here? ^ offer an acceptable middle ground between the PSK ciphersuite in terms of out-of-band validation and the functionality offered by asymmetric cryptography. I think I understand The use of PFS is a trade-off decision since on one hand the compromise of long-term secrets of embedded devices is more likely than with many other Internet hosts but on the other hand a Diffie- Hellman exchange requires ephemeral key pairs to be generated, which is demanding from a performance point of view. For obvious performance improvement, some implementations re-use key pairs over multiple exchanges (rather than generating new keys for each exchange). However, note that such key re-use over long periods voids the benefits of forward secrecy when an attack gains access to this DH key pair. but, just to make sure - is this saying that when you gain access to a DH key pair, you can decrypt back to the last time the device generated new keys, but no further (so, "Imperfect Forward Secrecy")? I'm guessing that based on "trade-off" in the first sentence, but I'm not sure what's being traded for performance improvement. In this text, On the other hand, the way DTLS handles retransmission, which is per-flight instead of per-segment, tends to interact poorly with low bandwidth networks. I'm assuming you are using "per-flight" in the https://tools.ietf.org/html/rfc5681 sense of the term ("FLIGHT SIZE: The amount of data that has been sent but not yet cumulatively acknowledged"), but that's somewhat obscure, especially outside of TSV, and there's no definition or reference for it in this document. Perhaps you could say something like On the other hand, DTLS handles loss by retransmitting the entire amount of data that has been sent but has not been cumulatively acknowledged, and this tends to interact poorly with low bandwidth networks. Just to make sure I understand, The ClientHello and the ServerHello messages contains the 'Random' structure, which has two components: gmt_unix_time and a sequence of 28 random bytes. gmt_unix_time holds the current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT). Since many IoT devices do not have access to an accurate clock, it is RECOMMENDED to place a sequence of random bytes in the two components of the 'Random' structure when creating a ClientHello or ServerHello message and not to assume a structure when receiving these payloads. is recommending that all IoT devices use a sequence of random bytes, even if they do have access to an accurate clock - is that right? Could you help me understand why Implementing the Server Name Indication extension is RECOMMENDED unless it is known that a TLS/DTLS client does not interact with a server in a hosting environment. isn't REQUIRED? This seems like a violation of the Principle of Least Astonishment ("we moved our server into a hosted environment to save money, and our sensor network quit working"). I don't understand this paragraph. To prevent the re-negotiation attack [RFC5746] this specification RECOMMENDS to disable the TLS renegotiation feature. Clients MUST respond to server-initiated re-negotiation attempts with an alert message (no_renegotiation) and clients MUST NOT initiate them. If you MUST tell the server you won't renegotiate, and you MUST not try to renegotiate yourself, how does these turn into a RECOMMENDS ("SHOULD")?
Thanks for a clear, easy to read document. At the start, I considered complaining about the page count, but I think you used those pages well. 4.4.1, paragraph after first numbered list: Can this be more precise than "breaks security"? Maybe something to the effect of "Comparing...is required to ensure the client is communicating with the intended server"? 4.4.3, and 23: Are there bootstrapping concerns with software update mechanisms? For example, what if you need to revoke a trust anchor on which the update mechanism depends?
Thanks for your work on this draft! It is very well written and provides helpful guidance with appropriate pointers that I hope gets picked up by many IoT vendors. I even tweeted about this one! It would be good to raise awareness on this draft/RFC. Nice job!
Just some editorial comments here that the RFC Editor isn't likely to catch: -- Section 1 -- UDP is mainly used to carry CoAP messages but other transports can be utilized This is worded oddly, as it looks as if it's saying that the main use of UDP is to carry CoAP messages. Please consider this instead: NEW CoAP messages are mainly carried over UDP, but other transports can be utilized END -- Section 3.1 -- However, since DTLS operates on top of an unreliable datagram transport, it must explicitly cope with the reliable and ordered delivery assumptions made by TLS. It must explicitly cope with the *absence of* reliable and ordered delivery. Please consider re-wording this. -- Section 4.4.4 -- There are various algorithms used to sign digital certificates, such as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). As Table 1 indicates certificate are signed using ECDSA. This initially confused me. First, the "such as" modifier appears to apply to "digital certificates", when it's actually meant to apply to "algorithms". Then the second sentence seemed to contradict the first, until I realized that it's incomplete. Please consider this: NEW There are various algorithms used to sign digital certificates; those algorithms include RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA). As Table 1 shows, in this profile certificates are signed using ECDSA. END -- Section 4.4.6 -- With certificate-based authentication a DTLS server conveys its end entity certificate to the client during the DTLS exchange provides. Something's wrong with this sentence (the part that begins with "during"), but I can't figure out what. -- Section 6 -- All error messages marked as RESERVED are only supported for backwards compatibility with SSL MUST NOT be used with this profile. You're missing "and" before "MUST NOT". -- Section 13 -- Implementations conformant to this specification MUST use AEAD ciphers. Hence, RFC 7366 and the Truncated MAC extension of RFC 6066 are not applicable to this specification and are NOT RECOMMENDED. To me, "not applicable" says more than "NOT RECOMMENDED". Why is this not "MUST NOT be used"? -- Section 17 -- To prevent the re-negotiation attack [RFC5746] this specification RECOMMENDS to disable the TLS renegotiation feature. Clients MUST respond to server-initiated re-negotiation attempts with an alert message (no_renegotiation) and clients MUST NOT initiate them. Doesn't the second sentence actually say that this specification REQUIRES (not "RECOMMENDS") disabling of the TLS renegotiation feature? -- Section 18 -- If at some time in the future this profile reaches the quality of SSL 3.0 a software update is needed since constrained devices are unlikely to run multiple TLS/DTLS versions due to memory size restrictions. I don't understand this. What does "reaches the quality of SSL 3.0" mean?
Section 4: Should this say MUST implement and perform...? Section 6 seems oddly placed.
Was there WG discussion of https://datatracker.ietf.org/ipr/2085/ and whether to proceed? The shepherd write-up doesn't say.
Thank you for including a lot of TCP-awareness in this specification. I had a few questions, but nothing at Discuss level. If you have questions about my questions, please ask, of course. In this text, A requestor attempts to establish a TCP connection to a DHCPv4 Server in order to initiate a Leasequery exchange. If the attempt fails, the Requestor MAY retry. you might want to give some guidance about reasonable intervals to wait before retrying, randomizing retry intervals, and/or backing off retry intervals to some conservative maximum value. This isn't a general-purpose client-server protocol, and you understand the use case better than I do (and I wouldn't try to offer defaults), so please just consider whether this would be helpful. In this text, In any of the first three possibilities, the DHCPv4 server can be assumed to not support TLS. In this case, the requestor MUST close the connection. is the assumption that all three possibilities would happen again if you retried the attempt with the same server? I wondered especially about the second possibility (server side TCP connection close, as a possible load-shedding strategy to reject a connection request that might work at another time). In this text, The Requestor attempts to read a DHCPv4 leasequery reply message from the TCP connection. If the stream of replies becomes blocked, the Requestor SHOULD terminate the connection after ACTIVE_LQ_RCV_TIMEOUT, and MAY begin retry processing if configured to do so. I'm not sure what "becomes blocked" means from the Requestor's perspective. I'm guessing the following paragraph, describing interaction with DHCPLEASEQUERYSTATUS, is the clue I'm missing, but if so, reversing the order of the paragraphs, and tying that more tightly ("becomes blocked, with no DHCPLEASEQUERYSTATUS messaging", or whatever the clue I'm missing is), would likely be clearer. I have pretty much the same question about the corresponding text for the server side in 8.1, If the TCP connection becomes blocked while the server is accepting a connection or reading a query, it SHOULD terminate the connection after a BULK_LQ_DATA_TIMEOUT. We make this recommendation to allow servers to control the period of time they are willing to wait before abandoning an inactive connection, independent of the TCP implementations they may be using. and in 8.2, If the connection becomes blocked while the server is attempting to send reply messages, the server SHOULD terminate the TCP connection after ACTIVE_LQ_SEND_TIMEOUT. This timeout governs how long the DHCPv4 server is prepared to wait for the requestor to read and process enough information to unblock the TCP connection. The default is two minutes, which means that if more than two minutes goes by without the requestor reading enough information to unblock the TCP connection, the DHCPv4 server SHOULD close the TCP connection. This text 8.3. Multiple or Parallel Queries Every Active Leasequery request MUST be made on a single TCP connection where there is no other request active at the time the request is made. Note that this is different than what was allowed in [RFC6926] section 7.7 for Bulk Leasequery requests. and the following two paragraphs are good, but I didn't see any corresponding description of whether parallel queries were allowed on a single TCP connection in Section 7, for Requestor behavior, and the Requestor would be the entity that does this wrong, wouldn't it? Or did I miss it? I've seen some use cases described in IESG evaluation e-mail that sounds like the Requestor and DHCPv4 server are close enough for a human to touch both at the same time, but Kathleen commented that some ISPs provide DHCP service to customer edge routers. Is it worth saying anything about firewalls and NATs treating TCP differently? Or would even those cases be part of a trusted network path, so no firewalls or NATs?
I think I recognise almost all of the security/privacy text we ended up with for the dhcpv6 equivalent - thanks for getting all that right! For Alissa and Ben - I'd be happier too if only secure mode existed here, but there was an argument (which I've forgotten) as to why we needed the insecure one - I think it boiled down to doing it on the same machine or that they'd do it no matter what the RFC says. (But I may be mis-remembering.) So while I agree with your points on that, I'm not sure we're (i.e. we as IESG) right to fight the battle again over this one when they're making this the same as the dhcpv6 one we already approved. Anyway, if you do fight the battle over and win, we should probably ensure any resulting edits also get done to the dhcpv6 equivalent spec which is with the RFC editor still.
Do you really want to discourage implementations that only support secure mode? Is there a reason not to make secure mode MTI? Do I understand correctly that insecure mode makes no attempt to authorize requestors? If so, that should probably be mentioned in the security considerations. (I note that 6926 had some words about access control in the security considerations, but if this draft has the equivalent, I missed it.) The fact that insecure mode at the server does not allow a requester to upgrade to secure mode seems brittle. That is, it's easy to configure things where the server and requester simply cannot talk.
I agree with Alissa's discuss questioning why this allows the insecure mode at all. The draft could use a general pass to clean up the use of 2119 keywords. There are a lot of redundant normative statements between sections, and within sections. There are 2119 keywords in places that really don't need them--you don't need a MUST or a SHOULD to just describe the basic workings of a protocol. They should be saved for places where an implementer has a decision to make, or is likely to do the wrong thing. I've captured some examples, but I know I didn't get them all. -- 3: "server SHOULD provide a mechanism to control which data is allowed" Why not MUST? "with the exception that a server responding to an Active Leasequery request SHOULD be able to be configured to prevent specific data items from being included in the response to the requestor even if they were requested by inclusion in the dhcp-parameter-request-list option." Redundant with previous. (Also, why not MUST)? -- 7.1: "If the attempt fails, the Requestor MAY retry." How many times? How often? -- 7.2: "A requestor SHOULD be able to operate in either insecure or secure mode. This MAY be a feature that is administratively controlled." Why only MAY? "When operating in insecure mode, the requestor SHOULD proceed to send a DHCPACTIVELEASEQUERY request after the establishment of a TCP connection." Why not MUST? Or more to the point, why does this need a 2119 keyword--it's simply how the protocol works? "The recommendations in [RFC7525] SHOULD be followed when negotiating this connection." Why not MUST? (Or as Alissa commented, why not "The recommendations in [RFC7525] apply") "the requestor SHOULD initiate the exchange of the messages involved in a TLS handshake " Why not MUST? When might it not do so? "If the handshake exchange does not yield a functioning TLS connection, then the requester MUST close the TCP connection." Is the requester allows to attempt a new connection in insecure mode? -- 7.3: "The DHCPv4 request MUST have an xid (transaction-id) unique on the connection on which it is sent." Redundant with previous statement. "the requester SHOULD place this highest base-time value into a query-start-time option" Why does this need to be a 2119 keyword? It seems like the requester can do this if it cares about catch-up data, otherwise skip it. (as indicated by the next paragraph) -- 7.4: " "Note that a DHCPACTIVELEASEQUERY request specifically requests the DHCPv4 server to create a long-lived connection " I thought the Requester created the connections. "This SHOULD be the last message on that connection, and once the message has been transmitted, the server SHOULD close the connection." Why are the SHOULDs not MUSTs? When might one send additional messages, or not close the connection? -- 7.4.1: "The requester MUST NOT assume that every individual state change..." Redundant with previous statement. -- 8.1: "Any options appearing in a DHCPTLS message received by a DHCPv4 server SHOULD be ignored." Why not MUST? When might a server chose not to ignore them? "If for some reason the DHCPv4 server cannot or has been configured to not support a TLS connection, then it SHOULD send a DHCPTLS message with a dhcp-status-code of TLSConnectionRefused back to the requestor." Why not MUST? When might it do something different? -- 8.1.1: Why not MUST? -- 8.4: "The server MAY close its end of the TCP connection after sending its last message, a DHCPLEASEQUERYSTATUS message in response to a query." This seems to contradict previous normative statements. But I suspect you mean something to the effect of "The server MAY end communication by sending a DHCPLEASEQUERYSTATUS and them immediately closing the TCP connection." -- 9: The section seems to have a lot of redundant 2119 keywords. *** Editorial: -- 7.3:, paragraph starting with "Note that until all the recent data..." This paragraph would make more sense after the explanation of base-time in the following paragraph. -- 8.2: "The DHCPv4 server SHOULD, but is not required to, keep track of a limited amount of previous binding activity" I suggest " ... limit the amount of previous binding activity it keeps track of..."
I previously had no comments after reading the draft and think it may help to explain why, even though I did see the option for an insecure mode. DHCP is *typically* used on local networks. Admins have other controls they can use and I hope they aren't too worried about their LANs physical security... they can use switches to separate out traffic - no one uses hubs anymore and they should control the equipment and wires. Additionally, I was thinking that this was IPv4 and was long decided, as well as the discussions that already took place with Stephen for similar text in the IPv6 equivalent. Since there was an option for a secure mode it could be used in other circumstances like an ISP's DHCP service to customers edge routers or any circumstance where a secure mode is warranted (and that's already stated in the Security Considerations). Security involves risk management decisions for operators and organizations and that has to be okay sometimes. Since there is an option to use a secure mode (with details on how to do that) when needed, my feeling was the current text is enough given other security controls and the option that could be dependent on the environment.
Ben has anything I might say nailed quite well; thanks.
I think it would help to explain the rationale for having both secure and insecure modes supported. In sections 7.2, 8.1, and 9, this is a bit of a strange layering of normative requirements: The recommendations in [RFC7525] SHOULD be followed when negotiating this connection. If you were going to use normative language here I think this would more appropriately be a MUST, but I would actually recommend something along the lines of "The recommendations in [RFC7525] apply" since the recommendations contained therein vary in their normative strength. Perhaps the security ADs have a preferred formulation, I'm not sure.
The shepherd write up does not mention if the XML has been mechanically validated. Hopefully it has.
You might want to consider removing the level of indirection in the Security Considerations as pointed out in the SecDir review. This is not critical, so I'll leave it up to the editors and AD. https://www.ietf.org/mail-archive/web/secdir/current/msg05974.html
This could have been a Discuss, but I don't think it needs to be ... I struggle with this text in Section 5. Remedies: At the other end of the spectrum the Ombudsteam could decide that the Respondent is no longer permitted to participate in a particular IETF activity, for example, ejecting them from a meeting or requiring that the Respondent can no longer attend future meetings. (The Ombudsteam can recommend, but can not impose, that a Respondent who is in a IETF management position be removed from that position. There are existing mechanisms within IETF process for the removal of people from IETF management positions that may be used as necessary.) I don't understand how a recommendation for removal works in practice. My understanding is that we're not adding a way to remove I-star folk from their positions, and what's available is the recall procedure in https://tools.ietf.org/html/rfc7437#section-7. So, who would the Ombudsteam make a recommendation to, in order to remove a Respondent? <speculation> I suspect that the most the Ombudsteam could do, is to point out the existence of the recall procedure to the Reporter and/or Subject, and trust that the right thing happens. My thought is that if privacy matters, having the Ombudsteam even initiate a recall petition tells the community quite a bit about what's happened ("the Ombudsteam is petitioning to recall Spencer, what did he do now?!?"). If a recall seems appropriate to the Reporter and/or Subject, they can tell as much or as little of their story as necessary, and they can decide what's necessary. </speculation>
(Minor addition to discuss#2 below, otherwise no change) I'm sorry to move from a yes ballot to a discuss on this one but I think the text has disimproved and some problematic changes have been made since I last reviewed this (which was -05). I'm unsure if I'll be moving from discuss back to yes or to abstain. Other than as noted, my comments (and all discuss points) are only on text changed since -05. (1) section 2: calling out creating an environment that is intimidating as a form of harassment goes too far I think. It is in the nature of the IETF to be intimidating to non engineers or to less qualified engineers. Feeling intimidated because one is ignorant and where nobody is trying to do harm is something that is ok. Trying to intimidate is not ok, attempting to intimidate because someone is young, old, etc. is not ok, but that was already stated. I think you need to strike the text about "creating an environment that would be intimidating." In an IM chat with Pete, we ended up figuring expressing this point like this might help "We don’t want the ombuds to have to figure out which of all possible laws in the world are applicable, and this sentence doesn’t add anything really, since the ombuds get to decide how to handle any complaint, whether it falls under any definition or not. So let’s just strike the sentence." If we got that result, I'd be fine with that rationale for doing the right thing:-) (2) section 2, last para: I do not want the IETF to be subject to the laws of all countries. This seems to do that. There are some possibly relevant laws in some countries that are such that the IETF can't reasonably ask me to agree with those. This sentence should go, or should say something else. Put another way: I read this as saying that we're asserting that the IETF has consensus on every applicable law everywhere. I do not think such an IETF consensus exists. (3) 5.1: The recall ctte can't re-evaluate? That is plain odd. Once matters are public to that extent I think that forces a re-evaluation for the sake of fairness. In cases where e.g. the IESG can quietly ask a chair to step aside that's not an issue, but it certainly would be with a public recall. A claim that the recall ctte aren't qualified is not enough to justify a potentially unfair public process like that IMO. (4) 5.1, 2nd last para: respect has to be earned it's not ok to just say "ombudsteam => correct" for such a new construct. I think this kind of text might be enough to be problematic if/when someone goes to court and claims these are unfair procedures. (5) 5.2: purpose "is to prevent all" - that's nonsense, there is no point in setting an impossible purpose. The purpose surely is to minimise harassment and the impact if harassment has occurred? If this BCP makes such impossible claims, and if someone does ever end up in court, I would expect that this BCP could not be defended. That seems like a bad plan to me. "make sure" and "ensure" in the 2nd para are also overstated.
Some of my comments on the changed text here are close to discusses, but I think if we resolve the discusses then we'll hopefully also fix what needs fixing below. - intro, 2nd last para: I'd prefer s/intended/only intended/ I do think we should ensure that the ombudsteam can't get out of control, to the extent any formalism would help there. - section 2, 3rd last para: What is the sentence starting with "One way..." supposed to mean? Are you trying to get at situations where someone demands favours of some kind (e.g. sexual?) in return for doing what they ought in any case do? I don't think it's useful to be unclear like that. - 3.5: Say if someone refuses to accept that a report has been dealt with for 5 years. Does the lead ombudsbeing continue to be part of the team for all of that time? Do they only handle the existing "case"? Is there no way to hand off and finally free our poor ombudsbeing in such a case? (There will be reporters who don't want to let go, and that could be a problem for team members.) Just extending the term isn't a good plan I believe. - 4.1: The respondent is not obliged to co-operate is a tautology and should be omitted. "May consider failure to co-operate" sounds a bit too threatening and is it really needed or useful here? - 4.1: All reports in writing? Why? I think that's a detail for the ombudsteam and they ought be allowed to decide that a word in the ear is the most effective thing to do. I of course agree that all reports of substance need to be dealt with in writing, but even in that case, I don't think you mean that the reporter has to use writing to report. - 5.1: Why does 5.1 say "Per section 5.1"? - 5.1: The two places you say that folks are not qualified are not needed (recall ctte and appointing body) and are I think counterproductive. Any such set of IETFers is actually reasonably likely to have some qualified folks and some not. (And for everyone to believe themselves qualified.) I think you want to say that (over time) we ought (grow to) respect the ombudsteam decisions which is a good goal, (over time) but one that can only be reached (over time) with good demonstrated performance and respect can't just be declared to be required. - 5.1: The AD specific bullet is odd. What if the remedy is to be applied to an IAB programme lead or liaison manager or directorate secretary? I think you could generalise, but at that point it's probably so obvious as to not need saying. Maybe delete that bullet. - 5.1, the last-resort bit: this is good but I think s/should consider/must consider/ is needed there. I can't see there being a case where the ombudsbeing wouldn't consider a lesser remedy and if they ever get to the last resort they really had better have documented (internally) that they did consider lesser remedies. - section 8: this is not only a summary, the last point was not previously made. I didn't check all the others. comments on text previously reviewed: - section 2: the term "potential harrassment" is weird, esp in "reports potential harrassment" - this would allow a reporter Bob to say that Charlie might be able to harrass Alice. That is always true. - 3.1: The 1st and 2nd sentences here contradict one another. Rewording can fix, e.g. s/shall/ought/ and s/will rapidly/ should rapidly/ - 3.2: "may consider elements of diversity" is bogus. Of course the IETF chair can do that. If we want the IETF chair to do so, we should say they ought, not that they may. Strike this or s/may/ought/ - section 4: Will normal web access logs to related web pages be kept? Maybe this'd be better on another domain? - 4.1: The ombudsteam set their own procedures but if the community are unhappy with those the only recourse is the (never used) recall for the IETF chair? That's not going to happen. I think you're missing a middle step where the IETF chair should fire the ombudsteam if the community don't accept team practices and the team don't fix those in response. - 4.1: This dives into too much detail in a number of ways. Let the team figure out those details. E.g., saying "do like nomcom" is a bit strong here, I'd allow the team to decide that. They could e.g. prefer to use some kind of whistleblower technology and no email at all. (The statement isn't entirely broken as-is, but is also not needed.) One could maybe say that the team need to be at least as careful as nomcom should be. - 4.1: The shall in "shall not be subject to retaliation" is wishful thinking. Nobody can control that. I think you want to say that good-faith reports ought not by themselves be considered a negative and that this is something on which the IETF has consensus.
I expect the following is just a matter of word smithing or my own comprehension, in which case I can quickly convert to a yes. I am concerned about some text that repeats several times in section 5 for different responsible bodies/persons: "the Recall Committee is expected to understand that their investigation as described in [RFC7437] is not to re-evaluate the events of the harassment, and that they are not qualified in handling issues of harassment." That can be construed to say that the responsible body cannot disagree with the recommendations of the ombudsteam. How can the body disagree without evaluating things? I don't think that is the intent. If the point is that they are not to re-investigate the facts of the matter, but may make their own decisions about the recommendations of the ombudsteam, I am fine with it--I'm just not sure the text supports that. (For the record, I do not object to the related expectation that responsible bodies take ombudsteam recommendations seriously.) Along those lines, there is a several-times repeated expectation that responsible bodies/persons will follow the recommendations of the ombudsteam. I would prefer not to presume the actions of such bodies. This could be taken as an expectation to rubber-stamp things.
Section 2: -- Reporter vs Subject: There are several mentions of roles the reporter might fill if there is no subject. I assume that also applies to situations where the subject does not want to make themselves known. But it seems to open up the possibility of a reporter pursuing something against the wishes of the subject, and that if a subject exists that person should be able to shut things down at any time. Is that correct, and if so did I miss some place it was covered? -- Stephen brought up the issue about creating a hostile environment, and mentioned the potential for situations where a hostile environment might be reasonable. In the paragraph starting with "This document concerns itself...", there's a reasonableness standard applied to interfering with participation. Does that also apply to creating a hostile or intimidating environment? -- I share Stephen's concern about the last paragraph incorporating laws from jurisdictions that we might not want to incorporate without examination. Section 4: -- Could the 2nd paragraph be expanded to cover some of Alissa's concerns? -- 5th paragraph: "... how the reporter can handle" Or subject? Section 6: "All elements of the appeal, including the fact of the appeal, will be held in confidence, but will be recorded and held securely for future reference." Why does an appeal of ombudsteam action require confidentiality beyond that already protected for the subject, reporter, and respondant. More to the point, I'm not sure why an ombudsperson would have an expectation of confidentiality about their own actions, beyond that incident to protecting the other parties.
I reviewed the version 9. One point I want to discuss before moving back to a YES. - It is not the intent that the AD re-evaluate the events, and the AD is expected to understand that they are not qualified in handling issues of harassment and they must preserve confidentiality. The AD is strongly encouraged to discuss with the Ombudsteam in the event that the AD feels removal from position is not the correct remedy. Btw, a nit: they -> he It seems that the two sentences contradict each other. "Strongly encouraged to discuss with the Ombudsteam in the event that the AD feels removal from position is not the correct remedy " but, at the same time, "is not the intent that the AD re-evaluate the events" If the Ombudsteam is really in charge, if "The Ombudsteam is expected to strive for confidentiality" (so basically the AD shouldn't know all the details), and if the "AD should not re-evaluate the events", should we remove this sentence? "The AD is strongly encouraged to discuss with the Ombudsteam in the event that the AD feels removal from position is not the correct remedy." Same remark for: It is not the intent that the AD or WG chairs re-evaluate the events, and the AD and WG chairs are expected to understand that they are not qualified in handling issues of harassment and that they must preserve confidentiality. The AD is strongly encouraged to discuss with the Ombudsteam in the event that they or the WG chairs feel removal from position is not the correct remedy. - There is also an issue with the second part of this sentence that contradicts "is not the intent that the AD re-evaluate the events" : In the event that an AD declines to follow the recommendation of the Ombudsteam as described in the previous bullets, and if the AD fails to convince the Ombudsteam of the reasons for this
The IESG statement must be updated with a link to the new BCP. Whether this is done with "This IESG Statement is superseded by BCP xx" or "The IETF's procedures for handling cases of harassment are documented in BCP xx" is less important to me ... even if I have a small preference for the superseded version, as the BCP integrates the IESG statement definition.
Thanks for your work on this draft. I have no new points to add, but like Barry will wait on the legal review. I didn't see anything that would prevent someone from multiple 2-year terms, so I think that text is ok if they are up for it as this is very difficult work.
I've re-reviewed the whole document, as well as focusing on the diffs between the last time and now. In the end I remain a "Yes", because I think it's important that we do this... but I share Alissa's concern about the over-formalized aspect of it. It's a shame that we're in a place where that's necessary. I'm afraid that there's no way we could possibly get consensus for any formal process without the sort of heavyweight specification we now have, which attempts to look into every nook and butter every cranny. I think some of that could be mitigated by some extra stuff at the beginning of Section 4 that makes it clear that the first steps in a harassment complaint could be less formal. A Subject could contact a Reporter, someone the Subject trusts, to get advice. Perhaps that Reporter could work with the Subject to determine a course of action the Subject would feel comfortable with, and that course might include having the Reporter talk less formally with the Respondent or with others who could help the situation. Section 4 might then say that if that sort of thing is not what the Subject wants, or if it's tried and doesn't work, the formal process could be taken on. My point here is to make it clear that there are options -- that this is meant to provide a formal process for when that is needed, but that the most important thing is for harassment issues to be handled in a manner that the Subject feels comfortable with (and that, as Alissa says, the Subject is in control of). I'm leaving this as a non-blocking comment. I know that the informal handling that might happen before a complaint is formally given to the Ombudsteam is out of scope for this document, but I'd like to see some outline included to make it clear that the choices are not to live with the harassment, to leave, or to invoke some Obuds-nuclear-bomb, as it might seem.
I share many of the concerns raised in Alissa's Abstain position.
I am balloting ABSTAIN on this document because I did not manage to find time to provide my thoughts when the document was being developed and discussed in the community. I do regret that. It seems inappropriate to hold it up at this stage and given how much discussion has taken place. When discussions about developing an anti-harassment policy first began I was in favor of the idea for two reasons. First, I thought we could improve the experience of attending IETF meetings by having a trusted person or people whom attendees could talk to and possibly strategize with if the attendees had experienced harassment. Second, I thought it was important to establish publicly the expectation that all attendees be treated with dignity, decency, and respect. The IESG policy accomplishes the second of these goals and this document seems aimed at accomplishing the first, among other things. I do not believe the document accomplishes the first goal, however. This is because the procedures as outlined turn what could have been the key incremental improvement -- having a trusted person for attendees to talk to -- into a legalistic pile of process and communications that I believe will deter victims of harassment from making use of the system at all. When I have a sensitive incident to report, I want to report it to a single person whom I trust. I do not want to have to agree a priori to having that information shared with a team of three people, nor do I want to be re-directed to some other person who I perhaps trust less. I do not want the person to whom I report it to write it down. I just want to talk it through with the person. Then, if we both agree that some further course of action is warranted, I want to be involved in deciding what course of action I am comfortable with, and I want to continue to be involved in deciding whether to proceed at every step of the way, including steps that involve informing ADs, the secretariat, and other parties. I want to reserve the right to change my mind at any time. The problem with the document as written is that it severely disenfranchises the victim of the harassment, to the point where I expect that most victims would be afraid to actually make use of the procedures outlined in the document. Being harassed can be scary. The policies outlined in the document have utterly failed to account for that. Furthermore, the document in sections 5.1 and 6 contemplates all manner of scenarios that may or may not come to pass and specifies detailed procedures for how to handle them. In practice I expect that there are probably scenarios we haven't thought of that will arise, while the ones for which detailed procedures have been specified might never get used. I wish we could have started with an incremental approach that achieves the two goals stated above, and then checked in after some implementation experience to see where the gaps are and what needs beefing up procedurally. Instead we are going from no process to an over-specified process without any implementation experience to build on. I hope I'm wrong about the potential utility of the process specified in the document, but I cannot support it as written.
I support Brian's Discuss.
- section 7: "If the transport network cannot be trusted, IPsec Authentication should be used to ensure integrity of the ConEx information." Hmm. Transport networks cannot be trusted so the first condition is always met. That means you are saying IPsec should be used. I don't see how the key management required is going to happen and even if it did, would that affect conex calculations? I'm ok with an experiment on that basis though, but it'd be better if the real relationship between this and IPsec were more fully fleshed out somewhere as part of the experiment. - The secdir review  touches on similar issues. I'm not sure if that got a response, but it raises a good point that seems to me to deserve a response.  https://www.ietf.org/mail-archive/web/secdir/current/msg05957.html
Section 4. (ConEx Destination Option (CDO)) defines the Option Length field by saying: "The sender MUST set this field to 1 but ConEx-aware nodes MUST accept an option length of 1 or more.” Maybe I just don’t understand the subtlety in that statement, but if all the senders use 1, why would the receiver want to accept any other value? To me it just seems like that would be an error/malformed option.
Thanks for including the paragraphs on the purpose of the experiment! There is an IPR declaration that lists this as an "associated draft". I'm not sure what to make of that, but it was not mentioned in the shepherd review. IDNits mentions some unused references.
The resolution from the Robert Spark's Gen-ART review needs to be folded in to the document before it is approved. Also, as noted in Ron Bonica's Gen-ART review and by Brian Haberman on the IESG review, there is a concern for using Destination Options this way. I wanted to be on record that I too am concerned about that. I'm not blocking on that comment because this is for Experiment RFC. But it is a cause for concern, even with the other option (HBH options) also has downsides.
As mentiond by Scott in his OPS-DIR review: As an experiment this should have few operational concerns for any network not involved in the experiment but if the technology becomes standardized at some later time it will add somewhat to the complexity of configuring network devices (i.e. routers). Bottom line, technology-wise this ID seems ready to publish. But I do have some comments on the use of rfc 2119 terminology in the ID. I do not think I’ve seen a case where a document says SHOULD NOT and MAY in the same paragraph referring to the same thing: As with any destination option, an ingress tunnel endpoint will not natively copy the CDO when adding an encapsulating outer IP header. In general an ingress tunnel SHOULD NOT copy the CDO to the outer header as this would changed the number of bytes that would be counted. However, it MAY copy the CDO to the outer header in order to facilitate visibility by subsequent on-path ConEx functions if the configuration of the tunnel ingress and the ConEx nodes is co- ordinated. This trades off the performance of ConEx functions against that of tunnel processing. I suggest that this be reworded to say something like “SHOULD NOT unless xxx, in which case it MAY xxx” The next paragraph says An egress tunnel endpoint SHOULD ignore any CDO on decapsulation of an outer IP header. The information in any inner CDO will always be considered correct, even if it differs from any outer CDO. Therefore, the decapsulator can strip the outer CDO without comparison to the inner. Why is this a SHOULD rather than a MUST? imo, SHOULDs should only be used when there is a known reason that an otherwise MUST behavior might not be followed – in that case the reason should be explained
I think this should be easy to address, but wanted to discuss options for the text in section 7. Since there is text that says IPsec Authentication should be used when integrity protection and the section goes on to also discuss encryption, shouldn't there be a similar statement that says IPsec encryption should be used when there is a need to protect confidentiality? Also, in reading this, I think because of the selected wording, I was thinking that it wasn't clear enough on the need/recommendation for authentication or encryption with IPsec since there are options for both to be set to NULL/none. You can have a NULL cipher-suite and you can also have authentication set to none to allow for opportunistic security negotiations (fairly new RFC for the latter). There's no need to mention these options explicitly, but rather to make it clear that IPsec can be used to provide authentication and encryption. So I think one additional sentence and some possible rewording in this section would be helpful.
For the Security Considerations section, I'd just ask that you add in "IPsec" when AH and ESP are first mentioned so this is clear.
I support the publication of this document given the need for experimentation in this area. However, there is one point that I would like to discuss... Section 3 contains R-1 which says that this marking "needs to be visible to all ConEx-capable nodes on the path." Additionally, Section 5 says that the choice of using an IPv6 Destination Option precludes non-ConEx-capable devices from having to deal with the extension header. However, RFC 2460 clearly says that Destination Options are not inspected by intermediate devices. We all know that a variety of intermediate devices ignore the rule in 2460. Given that, I would like this document to explicitly state that it does not abide by the rule in 2460 so that implementations that do follow 2460 but want to support this approach know to update all their extension header processing code.
* Why does the word "foo" appear in the middle of Section 4? * Do you want the Option Type description in Section 4 to have a value = TBD construct so that the IANA-assigned value can be inserted?
- There is a huge amount of sales-speak in this document. Frankly there is so much of that here, and no counterpoint nor real analysis that is technically, but fairly, critical of conex, that this seems like marketing material. Why are the authors, the WG, the area and the IETF producing that kind of thing? I'm sure there are good reasons to produce the material, but I'm not at all sure that ought be done within the IETF. - Same IPR comment as Ben's. Were the WG aware?
The security considerations section seems substantially incomplete. The phrase "include, but are not limited to" seems to indicate that people thought there were additional considerations. Please write them down, or explain why there really aren't additional considerations.
There is an IPR declaration that lists this as an "associated draft". I'm not sure what to make of that, but it was not mentioned in the shepherd review. This reads much like an advocacy white paper. There's useful information in it, but I would have preferred less of the marketing tone. But that's just me, and I don't expect that to change this late in the process.
Not too happy that a document on the IESG table doesn't take into account the shepherd feedback. See "A few editing nits that should be addressed before final publication: " at https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/shepherdwriteup/, which corresponds to Tim's OPS DIR feedback below. My review found several issues with the document references and discussions, and several of them mirror those of the document shepherd. I suggest the OPs ADs heed the document shepherd words. 2.3. Accounting for Congestion Volume 3G and LTE networks provide extensive support for accounting and charging already, for example cf. the Policy Charging Control (PCC) architecture. issue: There is no reference to the PCC architecture, even though its referenced several times. Section 2.4: [I-D.briscoe-conex-initial-deploy] provides specific examples of how ConEx deployments can be initiated, focusing on unilateral typo: unilateral 3.1. Possible Deployment Scenarios We present three different deployment scenarios for congestion exposure in the figures below: issue: There are 4 items listed numerically below this statement. Please adjust this. issue: The drawings are not close to the deployment scenarios. I would suggest doing the work to include each drawing with the appropriate scenario. issue: Figures 1-4 refer to objects "UE", "eNB", "S-GW", and "P-GW". These are not defined in the document anywhere. 6. Security Considerations Security considerations for applying CONEX to EPS include, but are not limited to, the security considerations that apply to the CONEX protocols. issue: There should be a reference to the draft that discusses the security considerations that apply to the CONEX protocols References: I-D.briscoe-conex-initial-deploy - "work in progress" is stated, but draft is expired. I-D.briscoe-tsvwg-ecn-encap-guidelines - also expired Appendix B: The EPS architecture and some of its standardized interfaces are depicted in Figure 1. This should be Figure 5, which is also distant from the description. More effort should be used to place descriptions and figures in close proximity.
Seems like a fine thing to experiment with. I hope the results are interesting. The security considerations really ought take into account or at least mention potential misbehaviour by middleboxes and also how conex might be affected by DoS attacks.
The IPR declaration at http://datatracker.ietf.org/ipr/1922/ lists this draft as a related work. I'm not sure what that means--but it's not mentioned in the shepherd write up. -- near end of 3.1: s/reransmission/retransmission
No objection to the document itself, but I really expect a new version based on Warren's feedback, as agreed by Suresh (document shepherd) Warren's feedback below. Be ye not afraid -- I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operation area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Version reviewed: draft-ietf-conex-tcp-modifications-09 Summary: I am not sure that this document is ready, and believe that review is needed from the Ops ADs. I believe that interactions with TCP feedback need to be performed very carefully, and I do not have the knowledge to adequately evaluate these, hopefully others with this experience (Transport ADs?) have also evaluated the document. The document needs significant readability cleanup and nit fixing. Detail: I found the document difficult to read -- there are a large number of typos, areas with lack of precision, ambiguities and grammar issues. This made a full evaluation difficult. I went to read the 'Document Quality' section of the Shepherd report to see if this was noted, but it was simply boilerplate. The document is marked as Experimental. I would be more concerned if it were a different stream... Open questions: Section 7 Open Areas for Experimentation; "This decision was taken because most network devices today expirience byte-congestion where the memory is filled exactly with the number of bytes a packet carries. However, there are also devices that may allocate a certain amount of memory per packet, no matter how larger a packet is." Citation needed; many devices I am familiar with split packets into multiple fixed size cells. e.g Juniper Q5 chips split packets into 96, 112, 128, 144, 160, or 176 byte cells and spray these across the fabric.I believe the Cisco CRS (and similar architectures) perform similar cell splitting. RFC7141 did not seem to contain this, but I may have missed it. In my opinion the document should discuss monitoring and reporting. What parameters should implementations expose to the user / operator? I think that the document should also discuss how this technique does or does not suffer from the potential of global synchronization (although this may be covered in other ConEx documents that I am not familiar with). The Security Considerations and Open Areas for Experimentation sections sort of discuss coexistence / deployment, but not in much depth Nits are readability issues - in a number of cases I was not entirely sure what was intended, so my suggestions may not be correct. Whereas loss has to be minimized, ECN can provide more fine-grained [O] Whereas loss has to be minimized, [P] Do you mean While, not whereas? I'm not sure how to parse this. feedback information. ConEx-based traffic measurement or management mechanisms could benefit from this. ... 3. Counting congestion ... The outstanding bytes counted based on ECN feedback information are maintained in the congestion exposure gauge (CEG), as explained in Section 3.2. When the sender sends a ConEx capable packet with the E or L flag set [O] When the sender sends a ConEx capable packet with the E or L flag set [P] When the sender sends a ConEx capable packet with the E or L flag set, [R] punctuation it reduces the respective counter by the byte-size of the packet. This is explained for both counters in Section 4.1. Note that all bytes of an IP packet must be counted in the LEG or CEG to capture the right number of bytes that should be marked. Therefore the sender SHOULD take the payload and headers into account, up to and including the IP header. However, in TCP the information how large the headers of an lost or marked pacekt were is [O] information how large the headers of an lost or marked pacekt [P] information regarding how large the headers of a lost or marked packet [R] readability, grammar, and typo (three changes) usually not available, as only payload data will be acknowledged. If equal-sized packets, or at least equally distributed packet sizes [O] or at least equally distributed packet sizes [P] or at least equally distributed packet sizes, [R] grammar can be assumed, the sender MAY only add and subtract TCP payload bytes. ... 3.1. Loss Detection This section applies whether or not SACK support is available. The following subsection in addition handles the case when SACK is not [O] The following subsection in addition handles [P] The following subsection (3.1.1) handles [R] Clarity available. A TCP sender detects losses and subsequently retransmits the lost data. Therefore, ConEx sender can simply set the ConEx L flag on all retransmissions in order to at least cover the amount of bytes lost. If this aprroach is taken, no LEG is needed. [O] aprroach [P] approach [R] spelling However, any retransmission may be spurious. In this case more bytes have been marked than necessary. To compensate this effect a ConEx [O] To compensate this effect [P] To compensate for this effect, [R] grammar sender can maintain a local signed counter, the (LEG), that indicats [O] indicats [P] inidicates [R] spelling the number of outstanding bytes to be sent with the ConEx L flag and also can become negative. Using the LEG, when a TCP sender decides that a data segment needs to be retransmitted, it will increase LEG by the size of the TCP payload bytes in the retransmission (assuming equal sized segments such that the retransmitted packet will have the same number of header bytes as the original ones): For each retransmision: [O] retransmision [P] retransmission [R] spelling LEG += payload Note, how the LEG is reduced when the ConEx L marking are set is described in section Section 4. Further to accommodate spurious restransmissions, a ConEx sender [O] restransmissions [P] retransmissions [R] spelling SHOULD make use of heuristics to detect such spurious retransmissions (e.g. F-RTO [RFC5682], DSACK [RFC3708], and Eifel [RFC3522], [RFC4015]) if are already available in a given implementation. If no [O] if are already available in a given implementation. [P] if already available in a given implementation. [R] grammar mechanism for detecting spurious retransmissions is available, the ConEx sender MAY chose to implement one of the mechanism stated above. However, given the inaccuracy that ConEx may have anyway and the timeliness of ConEx information, a ConEx MAY also chose to not componsate for spurious retransmission. In this case if spurious [O] componsate [P] compensate [R] spelling retransmissions occur, the ConEx sender simple has sent too much [O] retransmissions occur, the ConEx sender simple has sent too much [P] retransmissions occur, the ConEx sender simply has sent too many [R] grammar x 2 ConEx signals which e.g would decrease the congestion allowance in a ConEx policer unnecessary. [O] in a ConEx policer unnecessary. [R] ? Cannot parse. If a heuristic to detect spurious retransmission is used and has [O] If a heuristic to detect spurious retransmission is used [P] If a heuristic method is used to detect spurious retransmission [R] readability, and was missing a noun after heuristic. Could use analysis instead. determined that a certain number of packets were retransmitted erroneously, the ConEx sender subtracts the payload size of these TCP packets from LEG. If a spurious reransmission is detected: [O] reransmission [P] retransmission [R] spelling LEG -= payload Note that the LEG can get negative, if too many L marking have [O] Note that the LEG can get negative [P] Note that LEG can become negative [R] clarity already been sent. This case is further discussed in section Section 6. 3.1.1. Without SACK Support If multiple losses occur within one RTT and SACK is not used, it may take several RTTs until all lost data is retransmitted. With the scheme described above, the ConEx information will be delayed considerably, but timeliness is important for ConEx. However, for ConEx it is not important to know which data got lost but only how much. During the first RTT after the initial loss detection, the [O] However, for ConEx it is not important to know which data got lost but only how much. [P] For ConEx, it is important to know how much data was lot; it is not important to know what data is lost. [R] readability amount of received data and thus also the amount of lost data can be estimated based on the number of received ACKs. ... 3.2. ECN ... DeliveredData covers the number of bytes that has been newly delivered to the receiver. Therefore on each arrival of an ACK, DeliveredData will be increased by the newly acknowledged bytes (acked_bytes) as indicated by the current ACK, relative to all past ACKs. The formula depends on whether SACK is available: if SACK is not avaialble SACK_diff is always zero, whereas is ACK information is [O] avaialble [P] available [R] spelling available is_dup and is_after_dup are always zero. With SACK, DeliveredData is increased by the number of bytes provided by (new) SACK information (SACK_diff). Note, if less unacknowledged bytes are announced in the new SACK information than in the previous ACK, SACK_diff can be negative. In this case, data is newly acknowledged (in acked_bytes), that has previously already been accumulated into DeliveredData based on SACK information. Otherwise without SACK, DeliveredData is increased by 1 SMSS on duplicate acknowledgements as duplicate acknowledgements do not [O] as duplicate acknowledgements [P] because duplicate acknowedgements [R] grammar. Since would also be fine, instead of as. acknowlegde any new data (and acked_bytes will be zero). For the [O] acknowlegde [P] acknowledge [R] spelling subsequent partial or full ACK, acked_bytes cover all newly acknowledged bytes including the ones that where already accounted which the receiption of any duplicate acknowledgement. Therefore [O] the ones that where already accounted which the receiption of any duplicate acknowledgement [P] those already accounted for with the receipt of any duplicate acknowledgement. [R] spelling, grammar, inability to parse the original. I *think* this is what was meant. DeliveredData is reduced by one SMSS for each preceding duplicate ACK. Consequently, is_dup is one if the current ACK is a duplicated ACK without SACK, and zero otherwise. is_after_dup is only one for the next full or partial ACK after a number of duplicated ACKs without SACK and num_dup counts the number of duplicated ACKs in a row (which usually is 3 or more). With classic ECN, one congestion marked packet causes continuous congestion feedback for a whole round trip, thus hiding the arrival of any further congestion marked packets during that round trip. A more accurate ECN feedback scheme (AccECN) is needed to ensure that feedback properly reflects the extent of congestion marking. The two cases, with and without a receiver capable of AccECN, are discussed in the following sections. 3.2.1. Accurate ECN feedback With a more accurate ECN feedback scheme (AccECN) that is supported by the receiver either the number of marked packets or the number of [O] by the receiver either the number [P] by the receiver, either the number [R] grammar/punctuation marked bytes will be feed back from the receiver to the sender and is [O] feed back [P] fed back [R] spelling therefore know at sender-side. In the latter case the CEG can [O] therefore know at sender-side. In the latter case the CEG can [P] therefore know at sender-side. In the latter case, the CEG can [R] grammar/punctuation directly be increased by the number of marked bytes. Otherwise if D is assumed to be the number of marks, the gauge (CEG) will be conservatively increased by one SMSS for each marking or at max the number of newly acknowledged bytes: CEG += min(SMSS*D, DeliveredData) 3.2.2. Classic ECN support ... To extract more than one ECE indication per RTT, a ConEx sender could set the CWR flag continuously to force the receiver to signal only one ECE per CE mark. Unfortunately, the use of delayed ACKs [RFC5681] (which is common) will prevent feedback of every CE mark; if a CWR confirmation is received before the ECE can be sent out on the next ACK, ECN feedback information could get lost (depeding on [O] depeding [P] depending [R] spelling the actual receiver implementation). Thus a sender SHOULD set CWR only on those data segments that will presumably trigger a (delayed ACK. The sender would need an additional control loop to estimated [O] to estimated [P] to estimate [R] grammar which data segments will trigger an ACK in order to extract more timely congestion notifications. Still the CEG SHOULD be increased [O] Still the CEG SHOULD be increased [P] Still, the CEG SHOULD be increased [R] readability by DeliveredData, as one or more CE marked packets could be acknowledged by one delayed ACK. 4. Setting the ConEx Flags By setting the X flag, a packet is marked as ConEx-capable. All packets carrying payload MUST be marked with the X flag set, including retransmissions. Only if no congestion feedback information is (currently) available, the X flag SHOULD be zero, such as for control packets on a connection that has not sent any (user) data for some time e.g., sending only pure ACKs which are not carrying any payload. [O] Only if no congestion feedback information is (currently) available, the X flag SHOULD be zero, such as for control packets on a connection that has not sent any (user) data for some time e.g., sending only pure ACKs which are not carrying any payload. [P] The X flag SHOULD be zero only if no congestion feedback information is (currently) available (e.g. for control packets on a connection that not sent any user data for some time and is sending only pure ACKs that are not carrying any payload). [R] grammar and readability 4.1. Setting the E or the L Flag As described in section Section 3.1, the sender needs to maintain a CEG counter and might maintain a LEG counter. If no LEG is used, all retransmission will be marked with the L flag. Further, as long as the LEG or CEG counter is positive, the sender marks each ConEx-capable packet with L or E respectively, and decreases the LEG or CEG counter by the TCP payload bytes carried in the marked packet (assuming headers are not being counted because packet sizes are regular). No matter how small the value of LEG or CEG, if it is positive, the sender MUST NOT defer packet marking to ensure ConEx signals are timely. Therefore the value of LEG and CEG [O] No matter how small the value of LEG or CEG, if it is positive, the sender MUST NOT defer packet marking to ensure ConEx signals are timely. [P] No matter how small the value of LEG or CEG, if the value is positive the sender MUST NOT defer packet marking; this ensure ConEx signals are timely. [R] readability. will commonly be negative. If both LEG and CEG are positive, the sender MUST mark each ConEx- capable packet with both L and E. If a credit signal is also pending (see next section), the C flag can be set as well. 4.2. Setting the Credit Flag ... Recall that CSC will be decreased whenever congestion occurs, therefore CSC will need to be replenished as soon as CSC drops below [O] Recall that CSC will be decreased whenever congestion occurs, therefore CSC will need [P] CSC will be decreased whenever congestion occurs; therefore, CSC will need [R] grammar F. Also recall that the sender can set the C flag on a ConEx-capable packet whether or not the E or L flags are also set. In TCP Slow Start, the congestion window might grow much larger than during the rest of the transmission. Likely, a sender could consider sending fewer than F credits but risking being penalized by an audit function. However, the credits should at least cover the increase in sending rate. Given the exponential increase as implemented in the TCP Slow Start algorithm which means that the sending rate doubles every RTT, a ConEx sender should at least cover half the number of packets in flight by credits. Note that the number of losses or markings within one RTT does not solely depend on the sender's actions. In general, the behavior of the cross traffic, whether active queue management (AQM) is used and how it is parameterized influence how many packets might be dropped or marked. As long as any AQM encountered is not overly aggressive with ECN marking, sending half the flight size as credits should be sufficient whether congestion is signaled by loss or ECN. To maintain half of the packet in flight as credits, of course half [O] To maintain half of the packet in flight as credits, of course half [P] consider removing "of course" -- otherwise, put commas around it. [R] readability/grammer of the packet of the initial window must be C marked. In Slow Start marking every fourth packet introduces the correct amount of credit as can be seen in Figure 1. ... 5. Loss of ConEx information Packets carrying ConEx signals could be discarded themselves. This will be a second order problem (e.g. if the loss probability is 0.1%, the probability of losing a ConEx L signal will be 0.1% of 0.1% = 0.01%). Further, the penality an audit induces should be propotional [O] Further, the penality an audit induces should be propotional [P] Further, the penalty an audit induces should be proportionate [R] spelling x 2 to the mismatch of expected ConEx marks and observed congestion, therefore the audit might only slightly increase the loss level of this flow. Therefore, an implementer MAY choose to ignore this problem, accepting instead the risk that an audit function might wrongly penalize a flow. Nonetheless, a ConEx sender is responsible to always signal [O] responsible to always signal [P] responsible for always signalling [R] grammar sufficient congestion feedback and therefore SHOULD remember which packet was marked with either the L, the E or the C flag. If one of these packets is detected as lost, the sender SHOULD increase the respective gauge(s), LEG or CEG, by the number of lost payload bytes in addition to increasing LEG for the loss. 6. Timeliness of the ConEx Signals ConEx signals will only be useful to a network node within a time delay of about one RTT after the congestion occurred. To avoid further delays, a ConEx sender SHOULD send the ConEx signaling on the next available packet. Any or all of the ConEx flags can be used in the same packet, which allows delay to be minimised when multiple signals are pending. The need to set multiple ConEx flags at the same time, can occur if e.g [O] at the same time, can occur [P] at the same time can occur [R] unnecessary comma; grammar an ACK is received by the sender that simultaneously indicates that at least one ECN mark was received, and that one or more segements [O] segements [P] segments [R] spelling were lost. This may e.g. happen during excessive congestion, where [O] may e.g. happen uring excessive congestion, where [P] may happen during excessive congestion, if [R] readability the queues overflow even though ECN was used and currently all forwarded packets are marked, while others have to be dropped nevertheless. Another case when this might happen is when ACKs are [O] nevertheless. [P] [delete "nevertheless"] [R] readability lost, so that a subsequent ACK carries summary information not previously available to the sender. If a flow becomes application-limited, there could be insufficient bytes to send to reduce the gauges to zero or below. In such cases, the sender cannot help but delay ConEx signals. Nonetheless, as long as the sender is marking all outgoing packets, an audit function is unlikely to penalize ConEx-marked packets. Therefore, no matter how long a gauge has been positive, a sender MUST NOT reduce the gauge by more than the ConEx marked bytes it has sent. If the CEG or LEG counter is negative, the respective counter MAY be reset to zero within one RTT after it was decreased the last time or one RTT after recovery if no further congestion occurred. 7. Open Areas for Experimentation All proposed mechanisms in this document are experimental, and therefore further large-scale experimentation in the Internet is required to evaluate if the signaling provided by these mechanisms is accurate and timely enough to produce value for ConEx-based (traffic management or other) mechanisms. The current ConEx specifications assume that congestion is counted in number of bytes (including the IP header that directly encapsulates the CDO and everything that IP header encapsulates) [draft-ietf-conex-destopt]. This decision was taken because most network devices today expirience byte-congestion where the memory is [O] expirience [P] experience [R] spelling filled exactly with the number of bytes a packet carries. However, there are also devices that may allocate a certain amount of memory per packet, no matter how larger a packet is. These devices get congested based on the number of packets in their memory and therefore in this case congestion is determined by the number of packets that have been lost or marked. Furthermore, a transport layer endpoint, such as a TCP sender or receiver, might not know the exact number of bytes that a lower layer was carrying. Therefore a TCP endpoint may only be able to estimate the exact number of congested bytes (assuming that all lower layer header have the same length). If this estimation is sufficient to work with the ConEx [O] If this estimation is sufficient to work with the ConEx [P] If this estimation is sufficient to work with, the ConEx [R] readability signal needs to be further evaluated in tests in the Internet together with different auditor implementations. Further, the proposed marking schemes in this document are designed under the assumption that all TCP packets of a ConEx-capable flow are of equal size or that flows have a constant mean packet size over a rather small time frame, like one RTT or less. In most implementations this assumption might be taken as well and probably is true for most of the traffic flows. However, it should be evaluted how much the accuracy degrades if this precondition is not fulfilled, while the proposed scheme is used. Especially evaluating this with real traffic from different application is important to make a decision if the proposed schemes are sufficient or a more complexe scheme is needed. [O] However, it should be evaluted how much the accuracy degrades if this precondition is not fulfilled, while the proposed scheme is used. Especially evaluating this with real traffic from different application is important to make a decision if the proposed schemes are sufficient or a more complexe scheme is needed. [P] If this proposed scheme is used, it is necessary to evaluate how much accuracy degrades if this precondition is not met. Evaluating with real traffic from different applications is especially important in making the decision regarding whether the proposed schemes are sufficient or whether a more complex scheme is needed. [R] grammar, spelling, readability In this context the proposed scheme to set credit markings in Slow Start runs a risk to provide an insufficient number of markings which can cause an audit function to penalize this flow. Both the proposed credit scheme for Slow Start as well as the scheme in Congestion Avoidance must be evaluated together with one or more specific implementations of an ConEx auditor to ensure that both algorithms, in the sender and in the auditor, work propoerly together with a low [O] propoerly [P] properly [R] spelling risk of false positives (which would lead to penalization of an honest sender). However, if a sender is wrongly assumed to cheat, the penalization of the audit should be adequate and should allow an honest sender using a congestion control scheme that is commonly used today to recover quickly. Another open issue is the accuracy of the ECN feedback signal. At time of publication of this document there is no AccECN mechanism s pecified yet, and further AccECN will also take some time to be [O] s pecified yet, [P] specified yet, [R] spelling widely deployed. This document proposes an advanced compatibility mode for Classic ECN. The proposed mechanism can provide more accurate feedback by utilizing the way Classic ECN is speficed but [O] speficed [P] specified [R] spelling [O] loosing information [P] losing information [R] spelling this risk is in a real deployment scenario, further experimental evaluation is needed. The following argument is intended to prove that suppressing repetitions of ECE, however, is still safe against possible congestion collapse due to lost congestion feedback and should be further proven in experimentation: Repetition of ECE in classic ECN is intended to ensure reliable delivery of congestion feedback. However, with advanced compatibility mode, it is possible to miss congestion notifications. This can happen in some implementations if delayed acknowledgements are used. Further an ACK containing ECE can simply get lost. If [O] Further an ACK [P] Further, an ACK [R] readability only a few CE marks are received within one congestion event (e.g., only one), the loss of one acknowledgements due to (heavy) congestion on the reverse path can prevent that any congestion notification is received by the sender. However, if loss of feedback exacerbates congestion on the forward path, more forward packets will be CE marked, increasing the likelihood that feedback from at least one CE will get through per RTT. As long as one ECE reaches the sender per RTT, the sender's congestion response will be the same as if CWR were not continuous. The only way that heavy congestion on the forward path could be completely hidden would be if all ACKs on the reverse path were lost. If total ACK loss persisted, the sender would time out and do a congestion response anyway. Therefore, the problem seems confined to potential suppression of a congestion response during light congestion. Anyway, even if loss of all ECN feedback leads to no congestion [O] Anyway [P] Furthermore [R] tone response, the worst that could happen would be loss instead of ECN- signaled congestion on the forward path. Given compatibility mode does not affect loss feedback, there would be no risk of congestion collapse. 10. Security Considerations ... However, if the receiver is solely interested in making the sender draw down its allowance, the net effect will depend on the sender's congestion control algorithm as permanetly adding more and more [O] permanetly [P] permanently
Section 7 is nice -- thanks for the detail.
Section 3.1.1: s/a ConEx MAY also chose to not componsate/a ConEx sender MAY also chose not to compensate/ Section 4.2: s/To maintain half of the packet in flight/To maintain half of the packets in flight/
Thanks for documenting this. I may try it:-)
After thinking about the comments from Joel and Paul, I'm demoting the IPR question to a comment, since I think it's up to the Joel and the working group to decide if there should be any delay to work this out: The IPR disclosure at http://datatracker.ietf.org/ipr/2539/ says that due to the early state of the draft, license terms will be provided later. Obviously the draft is beyond early stages now. Does it make sense to ask for an update before progressing this draft? -- section 1, paragraph 7: "Thus, recursive resolver software such as BIND will not need to add much new functionality, but recursive resolver software such as Unbound will need to be able to talk to an authoritative server" It might be useful to mention the properties of BIND and Unbound that make the difference. -- 1, paragraph 8: "Because of the significant operational risks described in this document, distributions of recursive DNS servers MUST NOT include configuration for the design described here." This made my day!
Malicious third parties might be able to observe that traffic on the network between the recursive resolver and one or more of the DNS roots .... The primary goals of this design is to provide faster negative responses to stub resolver queries that contain junk queries, and to prevent queries and responses from being visible on the network. I've been wondering. So this mechanism is basically to speed up junk queries. What can a malicious third party do by observing junk queries. Nothing, I guess. I guess you want something like. OLD: The primary goals of this design is to provide faster negative responses to stub resolver queries that contain junk queries, and to prevent queries and responses from being visible on the network. NEW: The primary goals of this design is to provide faster negative responses to stub resolver queries that contain junk queries, and to prevent valid queries and responses from being visible on the network.
Thanks for addressing the comments made in the SecDir review and including the added text: https://www.ietf.org/mail-archive/web/secdir/current/msg06032.html I'm with Terry, this isn't new and I'm glad that is pointed out in the ack section.
Thank you for writing this document and describing how it is done and also the risks of doing this, and most importantly why it should not be done on a whim or by default. I concur that this is not a new idea. In fact I implemented a similar thing during my ISP days in the late 90's and it was certainly more beneficial then due to the low change rate of the root zone, and the absence of DNSSEC, along with slower network speeds, and less instances of anycasted root-serves. That said, the operational costs were the same and they have been well covered in the doc. Can you please pay a little attention to the first sentence of the security considerations? Its a doozy and I had to re-read it a couple time to be clear on its meaning. In the appendix, different locations to get the zone by AXFR are specified. Have you considered highlighting that the zone can be collected from authoritative points in other ways? e.g. - https://www.iana.org/domains/root/files (noting ftp and http methods. - https://http.l.root-servers.org (and plain http) (and of course there may well be others, but I'll refrain from boiling that ocean) I would also like to see the observation made that no public AXFR service (that I am aware of) uses TSIG, so the fetching party is at the general risk exposure of non-TSIG AXFR. Not so much in terms of modifying data in the zone (as it's signed and the DNSSEC support on the recursive resolver is a MUST) but in a MiTM effort to simply withhold new versions of the root zone in a DoS frame.
Thanks for writing a clear document that describes the approach and the potential pitfalls. As I noted earlier, I think this approach is untenable given the fragility it will introduce. Any chance we will see a management item in the near future marking the resulting RFC Obsolete? -- old comments below -- I can't decide if I should ballot Yes because this document does a good job of describing how to deploy this approach or Abstain because the fragility introduced in this approach appears to be untenable. In the meantime, can someone explain why this document is stating a requirement to deploy this approach with IPv4 only?
Are these reqs consistent with an additional RTT for key exchange? If not, why is that ok? 100 setups/second implies a real need for a 0RTT model for any key exchange. That has significant protocol design implications. I think you only need to note that, but that noting that is really needed. (This could for example affect the details of  or of later work similar to or built on . Full disclosure: I'm a co-author of .)  https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt
Why isn't the WG working to solve the requirements in this document? I ask because in general I think that requirement documents are good to motivate work and guide solutions, but their useful lifetime is not beyond that. The solution is then what should be published. I also ask because according to the March 2014 CCAMP Meeting Notes one of the authors said: “we have possible solutions...but before coming with solutions we want an agreement on requirements", but I don't see any work that seems to be related, nor any other document referring to it. Having said that, given that the document got all the way here, I won't stand in the way of publication.
Dynamic circuit and virtual circuit switching intrinsically provide guaranteed bandwidth, guaranteed low-latency and jitter, and faster restoration, By virtual circuit switching you mean gmpls signaled time or frequency domain allocation. Not any other mpls meaning of virtual circuit switching.
- The shepherd write up says no IPR declarations, but the tracker disagrees. Did the WG consider the (in this case fairly innocuous) IPR declaration?   https://datatracker.ietf.org/ipr/2200/ - Are there unexpanded acronyms here? Be worth a pass to check. - section 1: "plagued prior attempts" screams out that it needs a reference or two. - section 4: I'm surprised there is no mention of the possible impact of (D)DoS on this. Couldn't that affect path selection based on metrics? If so, shouldn't you say how?
Robert Spark's Gen-ART review comment should be taken into account: This document is all about considerations. Specifically, it discusses what to consider if you were to build a path computation function that uses the kind of information you get from the TE metric extensions in RFC7471 and draft-ietf-isis-te-metric-extensions. It does not appear to be requirements for standardization work - rather, it is information for operators to use when building functions that don't necessarily need standardization. However, it looks as if the document may have once contemplated actually specifying a path computation function, and has legacy text from that thought? The abstract says "This specification uses network performance data ... to perform such path selections." But this document doesn't perform such path selections (or specify how to do them). Section 1.1 says "The following are the requirements that motivate this solution." But this draft doesn't actually specify a "solution". It discusses what to consider if you were to build a path computation function. Could this be framed as a set of goals to keep in mind while building your own such function? The third paragraph of section 1.2 could use clarification. I suspect the word "even" in the 4th sentence should be removed, and the judgement in "There may be legitimate use" is out of place. Consider rewriting the paragraph using simpler sentences. Section 2.3 appears to be considerations specifically for interpreting the anomalous bit in one specific extension? If so, the introduction to the section should call that out. If not, the section's structure needs improvement. The section also calls out two questions, but only discusses one of them explicitly.
As mentioned by Sue in her OPS-DIR review: Status: Review with nits (very minor nits) General comments: Document is precise, well-written, and understandable to those who have read the documents this draft depends on. There is not a specific operations section, but this mechanisms would be included in a PCE or other calculation engine. This reviewer does not see any reason why additional text needs to be utilized. Individuals who write such algorithms and programs are utilizing these mechanisms to provide better paths. Nit #1: section 1.2 EF and AF abbreviations are not spelled out. Unless these are part of the RFC editor’s abbreviations, it should be spelled out. Nit #2: section 2.3.1 /Link Los sub-TLV/Link Loss sub-TLV/ /Sub-TLV[I-D-ietf.isis-te-metric-extensions]/sub-TLV [I-D-ietf.isis-te-metric-extensions] I would add: spell out the ERO abbreviation.
I'll follow Stephen's comments, especially on the DoS question.