IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-09-15. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
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
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
Telechat:
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
Telechat:
3.4.2 Returning items
1023 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
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Working Group News
1040 EDT Adjourned
(at 2016-09-15 06:00:06 PDT)
draft-ietf-hip-multihoming
One big general comment: The split between this document and draft-ietf-hip-rfc5206-bis-13 (still) seems a little artificial. draft-ietf-hip-rfc5206-bis-13 describes some general parts that actually covers both use cases. I guess it would be at least nice to spell out clearly in this document which parts of draft-ietf-hip-rfc5206-bis-13 are required to read (section 4 and parts of section 5) if that's is somehow clearly separately. E.g. I believe the following should be in draft-ietf-hip-rfc5206-bis-13 and not in this doc: "Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. " I this is more relevant for the case described in this document but is true for the general case. draft-ietf-hip-rfc5206-bis-13 stated the following but that's not the same because it only describes the peer side: " For each locator listed in the LOCATOR_SET parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address." What worries me more is that I believe that one would need to always read both documents to implement the peer functionality correctly. E.g. this documents says the following: "An Initiator MAY include one or more LOCATOR_SET parameters in the I2 packet, independent of whether or not there was a LOCATOR_SET parameter in the R1. These parameters MUST be protected by the I2 signature. Even if the I2 packet contains LOCATOR_SET parameters, the Responder MUST still send the R2 packet to the source address of the I2." However, when I read draft-ietf-hip-rfc5206-bis-13, it is not clear that there are specifications in this document that are important for a correct implementation. Smaller comments: 1) Regarding the following sentence: "In summary, whether and how a host decides to leverage additional addresses in a load-balancing or fault-tolerant manner is outside the scope of the specification." I agree that it is out of scope for this doc. But maybe it would be useful to provide pointers to existng work. The scheduling problem is well know and e.g. basically the same for MPTCP. 2) Regarding the following recommendation: "Although the protocol may allow for configurations in which there is an asymmetric number of SAs between the hosts (e.g., one host has two interfaces and two inbound SAs, while the peer has one interface and one inbound SA), it is RECOMMENDED that inbound and outbound SAs be created pairwise between hosts. When an ESP_INFO arrives to rekey a particular outbound SA, the corresponding inbound SA should be also rekeyed at that time." I believe I agree but why? 3) I (again) would find it easier to have section 4.9, 4.10, and 4.11 before 4.2-4.8. However, I guess that's a matter of taste. Alternatively maybe have most of the text from 4.2-4.8 in a separate supersection first and call it 'usage scenarios' or something like this, while summerizing the protocol actions in one subsection in the 'protocol overview' section because it seems that the actions are actually quite similar for all use cases, no? 4) Maybe indicate clearly what is recommendated in draft-ietf-hip-rfc5206-bis the following way: OLD "[I-D.ietf-hip-rfc5206-bis] recommends that a host should send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. " NEW "[I-D.ietf-hip-rfc5206-bis] recommends that "a host should send a LOCATOR_SET whenever it recognizes a change of its IP addresses in use on an active HIP association, and assumes that the change is going to last at least for a few seconds. "" 5) How does a host know about this? Can you give examples? "The grouping should consider also whether middlebox interaction requires sending the same LOCATOR_SET in separate UPDATEs on different paths."
- I think section 6 ought note the privacy issue that was relatively recently with WebRTC and ICE where a client might not want all of it's IP addresses exposed, as doing so could expose the fact that the client e.g. is using Tor or another VPN service. The issue being that in some locations, that information may be quite sensitive. 4.2 notes this but in a quite opaque way, ("may be held back") but it'd be better to say some more. 5.1 is also relevant maybe in that it says one "SHOULD avoid" sending info about virtual interfaces. Anyway, I think it'd be good to add some recognition of this privacy issue to section 6. I am not arguing that this draft ought specify the one true way to avoid this problem, but only that it be recognised. - 4.11: what's the concern about anti-replay windows? I didn't get that fwiw, not sure if that just my relative ignorance of HIP or if more needs to be said in the document.
I agree with Mirja that the split sounds a bit artificial.
I'm wondering if split-tunneling should be listed as a security consideration. I see the following in section 4.1 that might be used to help prevent split tunneling: In the outbound direction, as a result of SPD processing, when an outbound SA is selected, the correct IP destination address for the peer must also be assigned. Then also the entirety of section 4.3. I read this as split tunneling could be an issue in some circumstances depending on policy and it might be good to mention this in the security considerations section. Or let me know if I am missing some background that would prevent split tunneling so implementers don't need to be made aware of this consideration. Thanks.
Carlos Pignataro <cpignata@cisco.com> performed the opsdir review
draft-ietf-hip-rfc5206-bis
Some concrete comments: 1) Can you further explain the scenario assumed in these sentences! What is the middblebox supposed/expected to do? "In this case, the OLD SPI and NEW SPI parameters both are set to the value of the preexisting incoming SPI; this ESP_INFO does not trigger a rekeying event but is instead included for possible parameter-inspecting middleboxes on the path. " and "An additional potential benefit of performing address verification is to allow middleboxes in the network along the new path to obtain the peer host's inbound SPI." 2) Section 3.2.1. step 2: I guess the peer would also need to retransmit the UPDATE+ECHO_REQUEST if it doesn't get a reply in time? (Didn't check RFC7401...) 3) section 4: Can you give any hints how large the lifetime typically should be? Can only the original address have an unbounded lifetime (see section 5) or can I also set the lifetime value in a certain way to declare the lifetime of this address of unbounded? 4) section 4/5: maybe state more clearly that a 'new' LOCATOR_SET replaces the old one and therefore if a hosts sens a LOCATOR_SET is MUST include all active addresses. I believe that's what you are doing from the description in section 5 but it's never really spelled out... 5) section 5.4: How long will an address be in UNVERIFIED state in case the verification is not successful (no reply). Is there a timer? How often will the peer retry the verification test? How long does the peer wait until resending the verification packet? 6) section 5.6: The proposed Credit-Based Authorization seems quite complicated for me. First please state clearly the goal: I guess the scenario is that that you send data to the host and the host switches to new address. To be able to keep sending data with the same rate during the "switch-over 3-way-handshake" you need this credit system. So, what you actually need is to estimate the current sending rate in packets per RTT and take this number of packets as your credit. If you know the RTT you can simply count the packets. You can probably always estimate the RTT during the initial HIP 'handshake'/UPDATE exchange. If you don't have a way to update this RTT estimate during the connection, you might just use 2xRTT or 3xRTT to be safe... And more general comments: 1) Did you see any deployment problems because you don't expose a port number (at a know location above the IP header) with e.g. NATs? 2) Usually documents that obsolete another rfc have a "changes from RFCXXXX" section. Not sure if this is needed in this case when you move from experimental to proposed stanadard but given the rather larger number of changes, I would find it helpful. 3) I believe reading would be easier for me if section 4 would have been first but not sure... 4) This docuemnt states several times that mutlihoming is out of scope and only the handover case is described. I think it would be better to state this clearly at the very beginning and remove the other cases (I believe these are anyway kind of left-overs from the previous document.) 5) The security section should also talk about privacy concerns when exposing identifiers to middleboxes (see comment 1 above)
My review was based on the diff vs. 5206 [1], and turned up nothing new of note:-) Seems like a reasonable update to me. I do however agree about the privacy issue raised by Mirja wrt exposing locators. It is worth noting that, so that implementers have it flagged that they need to consider that - not doing so caused quite a fuss for WebRTC so better to not repeat that. [1] https://tools.ietf.org/rfcdiff?url1=rfc5206&url2=draft-ietf-hip-rfc5206-bis-13.txt
I have a couple of minor nearly DISCUSSes that should be easy to fix: This document doesn't have "Changes since RFC XXXX" section as required for any -bis document. Can you please convert Appendix A to be such a section? As this is a -bis document that obsoletes the original RFC 5206, its IANA Considerations section should be self contained. I think you should mention that IANA has allocated type 193 for LOCATOR_SET and type 46 for LOCATOR_TYPE_UNSUPPORTED Notify Message Type, as specified in RFC 5206.
I support Alexey's comment: This document doesn't have "Changes since RFC XXXX" section as required for any -bis document. Can you please convert Appendix A to be such a section?
I agree with Mirja's comment about including privacy considerations for exposure to middleboxes.
Mehmet Ersue mehmet.ersue@nokia.com performed the opsdir review
draft-ietf-pals-mc-pon
Is this extension to ICCP really compatible with section 10 of RFC7275? RFC7275 says "It ought not be deployed on or over the public Internet. ICCP is not intended to be applicable when the Redundancy Group spans PEs in different administrative domains" whereas this draft only refers to the "well-managed" stuff and says nothing about multiple domains, and this draft also refers to public contexts such as telephone poles. Can you justify for me how using ICCP here is safe? (It may well be, but I'm entirely unsure, probably mostly due to my ignorance of PON deployments.) The same point was made in the secdir review [1] which did get a response. Sadly, I didn't get how the response answered the question. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06762.html
I have a couple of minor blocking points I would like to discuss, but they should be easy to fix: 1) In 2.1.1 and other sub-sections: should sub-TLV format be defined now, even though you don't specify any sub-TLV? (or is it already specified in another document?) Should recipients ignore unrecognized sub-TLVs or do something else? Please clarify. 2) In 2.1.3: what is "system priority"? This is not explained. Please either add an explanation or a reference to a document that defines it.
I agree with Stephen's discuss and the SecDir reviewer.
I was surprised by this text in the Abstract, MPLS is being deployed deeper into operator networks, often to or past the access network node. because I don't think what this is saying, matches text like this in the Introduction, Multi-Protocol Label Switching (MPLS) is being extended to the edge of operator networks, as is described in the the Multi-Segment Pseudowires with Passive Optical Network (PON) access use case [RFC6456]. Is it "to the edge", or "past the access network node"? But if there's no reason to use a different description, you might consider using the same description in both places. Of course, you folks are the experts on how MPLS is deployed ... and maybe I'm just confused by which direction you mean when you say "deeper"! I am also interested in resolution of Stephen's Discuss.
draft-ietf-pce-pcep-service-aware
A few minor, mostly editorial comments: - Abstract: The abstract seems unnecessarily long. The point is to describe very briefly what the document is about. The more “motivating” text could be left to the intro. -3: Will this section have value to readers of the RFC, once the RFC is published? - General: A lot (if not most) of the instances of “MAY” would better serve as “can”. They seem to be saying that it is possible for an element to do something, rather than offering permission to do that thing.
- You're missing a reference for TCP-AO (RFC5925 I guess) - My understanding is that TCP-AO is not widely deployed. If it is expected that PCEPS will be, then it'd maybe be good to indicate that in section 9. - I would have thought that these extensions would provide new ways in which networks could lie about things in order to influence what paths are chosen. Is that new or was it already considered in the referenced RFCs? (Sorry, didn't have time to check right now.) If it is new, maybe it's worth a mention? Note: I'm not suggesting that this document specify the one true way to deal with that, just that it be noted, if it's useful to do that, but given one motivation offered is financial services, presumably not everyone trusts everyone to be entirely honest;-)
I have quite a few comments and some parts really need fixing as things seems wrong to me. However, all these things are no big issues in itself that do not justify a discuss. I strongly recommend to discuss these points and apply changes where appropriate to make these metrics useful by providing the right information. - This doesn't seem right to mean: "The link bandwidth utilization (the total bandwidth of a link in current use for the forwarding)" Especially the word "current" is irritating as I strongly assume you'd be interested in something like the average utilization...? - In general I would clarify that you always talk about averages and not the current values because those change too dynamically to use them for path computation. - section 3 could be removed. It didn't really help me and the normative language here is actually a little bit confusing to me. - section 4.2.1: This also doesn't seem to be fully correct: "An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the average delay variation of the Path." I would assume that the average path delay variation is NOT the sum of the link variation. What you get is the maximum variation of the average link delay variation... not sure if that's the best metric to provide for path computation. Maybe it would be more useful to use the maximum of the average link delay variation as an extimate for the path delay variation? Also not sure what exactly the next sentence should tell me: "An implementation MAY also use some enhanced composition function for computing the average delay variation of a path." - OLD: "The value for the P2MP path delay metric type (T) = TBD8 is to be assigned by IANA." NEW: "The value for the P2MP path delay metric type (T) is TBD8." Also in the next two sections... - The term "Link Bandwidth Utilization (LBU)" is really confusing because I thought that utilization always is a value in percentage. I would propose to go inline with [RFC7471] and [RFC7810] and call it "Utilized Link Bandwidth"! (Similar for next section) - section 4.2.2.: Really? "The actual bandwidth by non-RSVP-TE traffic can be calculated by subtracting the available Bandwidth from the residual Bandwidth ([RFC7471] and [RFC7810]). Once we have the actual bandwidth for non-RSVP TE traffic, subtracting this from LBU would result in LRBU." Isn't the bandwidth utilization/ulilized bandwidth inculding the Link Reserved Bandwidth Utilization...? Not sure if I get this part correctly... - section 4.2.3.1: OLD "A PCE that supports this object MUST ensure that no link on the computed path has bandwidth utilization (LBU or LRBU percentage) exceeding the given value." NEW "A PCE that supports this object MUST compute a path with LBU or LRBU percentage that does not exceed the given value." I don't think the thing stated in the original sentence is possible based on the given information in the LBU/LRBU. - "If, for a given request, two or more instances of a BU object with the same type are present, only the first instance MUST be considered and other instances MUST be ignored." Maybe it's better to consider the lowest value instead of the first instance? - "If a PCE receives a PCReq message containing a BU object, and the PCE does not understand or support the BU object, and the P bit is clear in the BU object header then the PCE SHOULD simply ignore the BU object." Isn't this the default behavior? How should a PCE that does support this draft/understand the BU object do any actions...? Similar, the next part: "If the PCE does not understand the BU object, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object) and Error-value = 1 (Unrecognized object class) as per [RFC5440]." Just remove those two paragraphs...? - In general, had the feeling that the order of the document is a little up-side-down. However, I'm not sure if changing the order helps. Maybe double-check (also to avoid redunancy)!
The document should probably say more about how frequently information can be updated and recomputation can occur; there's a possibility that too frequent adjustment creates a flip flop effect where traffic moves to a new path, performance degrades, etc. I was curious about the definition of the P2MP packet loss as being the highest among the individual path losses. Is there some basis in some measurement documents for instance for this definition? It would seem to me that other definitions would also be possible, e.g., ones that take the aggregate loss into account in some fashion.
The authors and the OPS DIR reviewers (Jouni and Al) agreed on some new text.
The security sections of the referenced documents look very good. The one thing I don't see mentioned is use of these metrics to perform network reconnaissance to perform other attacks. I'm also interested to see the responses to Stephen's questions. Thanks.
ALFRED MORTON <acmorton@att.com> performed the opsdir review. subject to the discussion on the caculation of the path delay variation metric coming to a close, I have no objections.
draft-ietf-dnsop-nxdomain-cut
One minor question: In section 2, paragraph 3, which behavior is "this behavior"? The continuing to use cached data under the cut, or the cached non-existence itself?
I honestly look forward to reading DNSOPS drafts because they are uniquely chatty, and this one is no exception (awesome document title, dude). That said, This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it updates both of them. being "a bit modified" is like being a bit dead (either you're dead or you're not), so maybe that's TOO chatty? This draft was very clear to me, as a non-DNS reader. Thanks for that. Just for my own education, But if a resolver has cached data under the NXDOMAIN cut, it MAY continue to send it as a reply. (Until the TTL of this cached data expires.) I found myself wondering why this behavior is allowed. Is this a performance thing, that you continue to respond normally until normal TTL expiration happens with no special processing required, or is this about the non-tree cache implementations described in Section 6, or is there more to it than that? Perhaps that's worth a word or two explaining. In this text in Appendix A, Even if the accompanying SOA record is for example only, one cannot infer that foobar.example is nonexistent. The accompanying SOA indicates the apex of the zone, not the closest existing domain name. it's not clear that this practice is OK, and (especially from the example that will be deleted), it seems dodgy to the uninitiated. Perhaps it's worth saying so clearly (if it is, in fact, OK).
I like the sections 3.1 and 3.2. These are in line with the recent discussion on the wgchairs mailing list, and https://tools.ietf.org/html/draft-wilde-updating-rfcs-00. Copying erik.wilde@dret.net
In a very poor attempt at not showing my own geek level too much here, this document was a pleasure to read, well constructed, and a perfect fit for the ambiguity in 1034. Thank you!!
draft-ietf-nvo3-arch
- (This comment is just a generic remark, offered in the hope that future IPR declarations might be more tightly targeted, so there's no need to respond to it.) It's not clear to me how an architecture with 2 RAND-with-fee IPR declarations amounts to a win here. Well, unless the IPR is rubbish maybe - I did take a look at those and do have an opinion, but I'll leave you to guess what that is:-) But the IPR declarations seem like they were timely, and the last call did mention them, so I guess it is what it is. Generally though, I think it'd be way better if IPR declarations were attached to specific protocol documents that the IPR holders consider relevant and not to architecture documents or similar. I can understand that making an IPR declaration on a document like this might be seen as getting the declaration out earlier (a good thing), but one has to wonder how anything here represents a credible invention. If that's the case I'd note that IPR declarations can be made that don't point at an Internet-draft which might be a better way to provide earlier notification to a WG. And declarations can be updated later to be associated with specific drafts if/when that's needed. - Generally this was pretty well written, thanks. - abstract/intro: "work with other components with no changes to other components" isn't great, suggest re-wording. - 4.2: ToR could do with an expansion on 1st use - 4.2.1: TS - I assume that's "tenant system" (from 7635) but you should say as it's used a good bit (and 7635 also defines "tenant separation" making TS potentially ambiguous). Mostly, uses of TS seem clear from context, but I think it'd be good to fix this and to check over where TS is used in this draft as there could be some subtlety there, e.g. whether or not a TSI is part of a TS or not (and is somehow architecturally "beside" a TS) could affect some later protocol work. - section 16: I think it might be worth noting here that meta-data and operational data could be unexpectedly sensitive, for example performance statistics could be used to infer what's being done in a VM or VN. So in addition to encrypting data in transit or storage, one might also want to consider minimising the types of data that NVEs/NVAs collect. That could have an impact on protocols defined later so may well be worth noting here too. If you do add text on that you may also want to recognise the tension between such data minimisation and the operational need to detect misbehaviours or errors happening within VNs.
Two tiny comments: - Call section 4.5 "Virtual Access Point (VAP)" instead of only "VAP" - I don't really understand this: "As is the case for L2VPN, there is a client/server relationship between the overlay and underlay networks..." How do the terms client and server help me here? More general: I was hoping to find a discussion on how existing protocols would be applicable to the three needed control protocols. Also do these three protocols need to be three different protocols or could all three cases potentially be covered by the same protocol (because the protocol mechanisms are the same and maybe even sometimes the same information needs to be exchanged)?
* Section 3.1.2 : I am trying to understand why a minimum TTL decrement is expected here. I think the mandated behavior is incorrect and needs to be fixed. For L3 service, Tenant Systems should expect the IPv4 TTL (Time to Live) or IPv6 Hop Limit in the packets they send to be decremented by at least 1. e.g. Consider two IPv6 end systems that are connected using an L3 service. If one of them is the router and another is a host on the same network a significant part of the Neighbor Discovery functions will stop working if the hop limit is decremented (from 255 to 254).
* For an architecture based on tunnels I found the lack of discussion concerning MTUs and fragmentation a bit disconcerting. Has the WG discussed this?
draft-ietf-mptcp-experience
I support Stephen's comment, and have a few minor comments of my own (none of which are showstoppers): -1, first paragraph: I'm not sure we should describe an experimental RFC as "standardized". -1, mention of iOS7: Is this really limited to iOS7 and not future versions? Would it make since to say that "Since September 2013...is also supported ... iOS"? (i.e. without the version?) (Noting that iOS10 released this week...) - 2.2, paragraph 9: Figure 1 just shows a generic 2 path connection. It doesn't seem to "summarize" the described scenario. -2.2, 2nd paragraph after figure 1: I'm pretty sure there are in fact real applications that transfer bulk data. Do you mean to say that "Some [or even many or most] real applications do not..."
This is a great document, thank you for writing it. I have one small change request though (based on Dan Romascanu's Gen-ART review): > Multipath TCP was standardized in [RFC6824] Please change this to "specified" (RFC 6824 is experimental).
I would also like to request that the authors look at Dan's other comments: --- Summary: Ready with issues A very useful and well written document, which gathers implementation and deployment experience and expands the list of the Multipath TCP Use Cases. A few minor issues described below, if addressed, could improve the clarity and usability of the document. Major issues: Minor issues: 1. The 'Introduction' section starts with the statement: Multipath TCP was standardized in [RFC6824] and five independent implementations have been developed. Saying 'was standardized' seems misleading to me, as RFC 6824 is an experimental RFC, so not even standards-track (this putting aside the discussions whether RFCs are standards). Actually at no point this document mentions that Multipath TCP is Experimental, this seems odd. 2. It would be useful to clarify the statement about the iOS implementation of Multipath TCP in the Introduction by mentioning what 'single application' is referred. However, this particular Multipath TCP implementation is currently only used to support a single application.' 3. I am questioning whether the 'Multipath TCP proxies' section really belongs to the use cases or rather to operational experience. After all it's about a strategy of deployment of Multipath TCP in cases where clients and/or servers do not support Multipath TCP but the need exists probably because of the combination of one or several other use cases. 4. In section 3.5: There have been suggestions from Multipath TCP users to modify the implementation to allow the client to use different destination ports to reach the server. This suggestion seems mainly motivated by traffic shaping middleboxes that are used in some wireless networks. In networks where different shaping rates are associated to different destination port numbers, this could allow Multipath TCP to reach a higher performance. As of this writing, we are not aware of any implementation of this kind of tweaking. Beyond the potential problems described in the following paragraph, is such a 'tweak' consistent with the protocol definition, or would it need to cause changes in the protocol as defined now? A clear recommendation seems to be needed here. 5. A more clear recommendation would be useful also in 3.8. It is not clear here whether the segment size selection is a design or a tuning issue that can/should be added to applications. Nits/editorial comments: 1. Section 3.12 contains a timed statement 'As of September 2015 ...' which should be updated or maybe edited to make it less time-dependent. 2. It seems to me that [RFC6824] and [RFC6181] should be Normative References as they describe the protocol extensions, and the initial list of use cases which is expanded by this document. Without reading these two documents, this one does not make too much sense.
Thanks for this document. - This document contains a couple of possible improvements. I believe this important aspect of the draft should also be mentioned in the abstract. - Just a thought (no need to reply): On one side, section 3.1 speaks of "middlebox interference". On the other side, this document via [I-D.lhwxz-hybrid-access-network-architecture] proposes just that: a new middlebox function. This new middlebox might generate some interference for others. Sarcasm warning: I guess that middleboxes are like children, we can only stand ours. I wanted to make that point, in light of all the middlebox discussions these days, for example in the QUIC charter. - Another thought (again no need to reply) "Since September 2013, Multipath TCP is also supported on smartphones and tablets running iOS7 [IOS7]. There are likely hundreds of millions of Multipath TCP enabled devices. However, this particular Multipath TCP implementation is currently only used to support a single application. Unfortunately, there is no public information about the lessons learned from this large scale deployment." Yes, this is really unfortunate. Below is Qin Wu's OPS directorate review: I think this document is well written and ready for publication. Here are a few editorial comments: 1. Section 1, paragraph 2 mentions that three implementation are open sources. Which three of them are open sources? I think it includes apple MP-TCP, but it is not clear in the text. 2. Section 2.2 paragraph 7 points out using REMOVE_ADDR option may cause operational problem, but I don’t see any discussion on this in the operation experience section, is this an open issue that needs to be addressed in the future or other document? 3. Section 3.1 talks about the v0.87 Multipath TCP implementation What does V0.87 stands for? Version number? is there any reference to it? 4. Section 3.2 s/the the default congestion control/ the default congestion control 5. Section 3.2 last paragraph said that Reports from some users indicate that they seem to favor OLIA. It looks this statement is groundless statement. 6. Section 3.9 s/ returned to the DNS query/return in response to the DNS query 7. Section 3.10 said: “ A better approach would probably be to try a few attempts on the WiFi interface and then try to use the second interface for the initial subflow as well. ” When trying to use second interface for initial subflow? A few attempts on the WIFI interface fails? 8. Section 3.2 s/accomodate/accommodate
I agree with Stephen's comments.
Should this text The FTP interference is expected and due to Application Level Gateways running home routers. be "running in home routers"? I'm not sure how to parse the sentence otherwise. When reading this text This may be excessive in some environments, in particular when the client and/or the server have a large number of interfaces. I am reminded that multiple IP addresses per interface are common in IPv6 and dual stack deployments. That would make the situation worse, wouldn't it? If so, would that be worth saying?
I was a bit sad that there was no reporting of experiences with the security aspects of MPTCP. Have we really learned nothing worth saying about that? Have we really seen no attacks on, or tailored to, MPTCP? It seems odd that the answer to both questions is "no."
Qin Wu <bill.wu@huawei.com> performed the opsdir review. he had quite a sfew small editorial comments that may be of use to the authors.
draft-moriarty-pkcs1
no objection to the publication of the rsa specification
draft-moriarty-pkcs5-v2dot1
Below is Bert Wijnen's OPS DIR review: I did OPSDIR review for this document. Such reviews are primarily intended to check if there is any operational or network management impact. I do not see any such impact/aspects in the document, so I think the doc is ready for publication from this perspective. Some nits/questions: - Section: 5.2. PBKDFs should that be: 5.2. PBKDF2 ??? - I am somewhat surprised to see that ALL references are normative. even a reference to a slide deck: [WANG] X. Wang, A.C. Yao, and F. Yao. Cryptanalysis on SHA-1. Presented by Adi Shamir at the rump session of CRYPTO 2005. Slides may be found currently at <http://csrc.nist.gov/groups/ST/hash/documents/Wang_SHA1-New- Result.pdf>
conflict-review-thomas-namecollisions-workshop-report
Useful document, thanks. I couldn't see the list of participants at [1]. I did see the list of speakers and ctte members there, so maybe that was the same? [1] http://namecollisions.net/
Nice and useful doc.