IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2011-09-08. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
1255 EDT break
1300 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1336 EDT Adjourned
(at 2011-09-08 07:28:13 PDT)
I've cleared my DISCUSS. Thanks for addressing my DISCUSS and COMMENT issues in my previous review.
Some pretty substantive changes have been made since revision -07 that came out of the WG, went to IETF last call, and was reviewed by the IESG. For example, sections 4.3 and 4.4 introduce new protocol elements. Surely these changes should at least get sign-off by the WG, and probably should be subject to renewed WG and IETF last calls.
Thank you for fixing my earlier Comment
There has been quite a bit of discussion about the Gen-ART Review by Pete McCann on 14-Apr-2011, yet the biggest issues have not yet been resolved. I do not understand why this document needs to state any requirements for connections on different access technologies back to the "home" LMA. Why not allow handoffs with a client-based solution without this requirement? Doesn't this approach prevent the MN from subscribing to different operators for each access technology.
Please consider the minor and editorial comments from the Gen-ART Review by Pete McCann on 14-Apr-2011.
Section 7. Configuration variables starts by mentioning that three configuration variables are defined in the document, and then defines ... two. Also - why are these called 'configuration variables' and not 'configuration objects'?
A couple of reference issues: ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
(1) It seems like there should be more of an explicit statement about what's advisable for an application to do if setting up and using a WebSocket connection fails. For instance, is it then acceptable for them to fall back to RFC 6202 techniques, if those might work for them? (2) Was there an intention to "Update" RFC 2616? Based on the document and the IETF list discussion, I got the impression that the answer is definitely "no", but it doesn't seem like there's much (or any) discussion in the document about the relation between this and 2616. Since this is using some of the 2616 behavior to get rolling, but makes some additions to it, and then has a totally different flavor afterwards, it seems like a fair question, and it wasn't clear if the working group thought about it.
In section 4.2.2, is the "might" really a MAY or is it a SHOULD?
First one's a "discuss discuss", the others should I hope be fairly easily handled. (0) p23: There is no version negotiation here, right? What happens if the masking algorithm turns out to be problematic or some other protocol bug needs fixing and a new version of this protocol is needed - how will clients and servers get updated to a new version without a flag-day? (Given that not all clients will be downloaded scripts.) (1) p20: Are the new header field names case sensitive? That is, would "sec-wEBSocket-kEY" be ok? I guess so, but saying that (maybe by saying that the rules from 2616, section 4.2 apply?) would be good. Not sure where best to put that text. (2) p21: I guess if the request includes other things like cookies or Authorization header fields, then those MUST be processed the same way that a HTTP server handles them. I think you should say that if it's true, and even if it's only definitely true if no websockets extensions are used. (3) p21: Do you also need to say which optional HTTP header fields MUST be supported by a websockets server? (Or, is there a general get-out-of-jail sentence somewhere that says that a server MUST do all the things a web server can do?) I'm not trying to insist on an exhaustive list which I guess might be controversial, but the more you can say here, presumably the more that interop will be improved? (4) p23: this says the version MUST be 8, earlier it said the client MUST send 13 - is that a (discuss-grade:-) typo or am I confused? (5) p24, "If the server supports encryption..." Why is TLS not a MUST-implement here? I think TLS should be mandatory to implement for both clients and servers, which needs to be stated, and then the text here might say "If the server has TLS turned on..." or something like that. I could live with a SHOULD implement, if there's a good reason for that, but I'd expect that MUST implement would be ok for this. Note that I'm not asking for "MUST use" and, given your definition of client and server is fairly loose, I'd imagine this ought be painless. And a related point on p55 - WSC actually only says what are *not* considered strong algorithms. Why not reference the MTI ciphersuite from TLS 1.2 here and be done with it? (6) p30/31: Is it required to use the minimum number of bytes to encode the payload length? E.g. could I use the 127-case for a payload of of 8 or 8000 bytes? (Also, you only specify that the MSB of the length field MUST be 0 for the 127-case. Is that correct? Put another way, if the payload length is 65535 exactly, can I use the 126-case with 0xffff as the value? I guess yes, but just checking.) (7) p34: how does fragmentation support multiplexing? I don't see how that works (without extensions). You should say that extensions are needed for multiplexing if that's the case. (8) p37: you don't say that a ping frame can have a payload nor whether that is masked (and similarly for the pong frame application data). (9) p53: The attack model in 10.3 is not clearly described, and while the claim of "provable" security is made, that is not substantiated, either here or via references. Since this is the justification for the masking scheme, I think this needs to be fixed. I suggest removing the "provable" wording, adding an informative reference to  with a strong recommendation to go read that, and maybe reducing the amount of text in 10.3 since the paper does a much better job.  http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla- jackson.pdf (10) I think the last call comments about the traffic profile  for websockets being different from HTTP sounds like its worth including something. While there seems to be controversy about what to say, I'd hope that some agreed text could be figured out.  http://www.ietf.org/mail-archive/web/ietf/current/msg69148.html
- p20: code "running on www.example.com" is an odd phrase, I think you mean code "running that was downloaded from www.example.com" - p27: referring to "Paragraph 4 of Section 4.2.2" from within 4.2.2 is odd and probably wrong depending on how you count paragraphs. Suggest rewording. - p29: If the ABNF and the introductory text in 5.2 were to be in conflict, which takes prededence? I'm not saying there is a conflict, but that kind of thing happens, so picking one as normative might be useful just in case. - p30: the "%x" notation is odd - why not just specify the values in decimal? If you prefer hex, I'd find 0x8 clearer than %x8. - p30: you don't say until 5.5 that opcodes 8-10 are control frames, but you depend on that in 5.4 where you say "control frames MAY be injected...". Better to move the text at the start of 5.5 earlier. - p33: why does "to be defined later" appear here? (twice) That chunk of ABNF seems a bit flakey since all four frame-*-*-data are just the same binary stuff. - p33: I guess masking is pretty useless if TLS is in use end-to-end, but is still done even with TLS in case the TLS endpoints aren't the websocket endpoints. Is that right? If so, it might be worth pointing out. - p36: why no ABNF for control frames? - p38: "A response to an unsolicited pong is not expected." seems vague. Can't you not say what MUST or MUST NOT happen? - p44: Providing some reference for the "Certain algorithms and specifications..." mentioned in 7.1.7 would be good. (Same comment for 7.2.1 & 7.2.2) typos: - p21: s/doesn't contains/doesn't contain/ - p23: s/a "Origin"/an "Origin"/ - p27: s/other section of/other sections of/ - p36: s/if streaming API/if a streaming API/ - p39: s/base protocols/base protocol/ - p50: s/other section of/other sections of/ - p52: s/in a case of/in the case of/ - p54: s/,TLS authentication./ or TLS authentication./ in 10.5 - p69: s/didn't necessarily endorsed/don't necessarily endorse/
The Gen-ART Review by Richard Barnes was updated to cover the -13 version of this document. The updated review can be found at: http://www.ietf.org/mail-archive/web/hybi/current/msg08683.html. The -13 version of the document seems to be better than the earlier version, but there are two concerns that need further discussion: 1. The browser must be prepared to buffer effectively infinite data, either from a single frame of 2**64 octets or from a single frame of unlimited fragments. 2. The masking technique is trivially circumvented and firewalls must undergo significant update to inspect essentially plaintext content that will now be carried on ports 80 and 443.
Section 1 has lots of "_This section is non-normative._" That convention isn't defined until section 2, so it's pretty silly to see them in section 1. But even so, I don't think it clears up anything. I would prefer to remove them. 4.1 - "Additionally, if the client is a web browser, an /origin/ MUST be supplied." Also see sub-bullet 8 of the handshake: "The request MUST include a header field with the name "Origin" [I-D.ietf-websec-origin] if the request is coming from a browser client." What happens if a web browser doesn't supply an origin? And how would you know if a web browser didn't do this? (That is, how can you distinguish it from a non-web browser?) I don't see how this can be a MUST. 4.1 - "In a Web browser context, the client SHOULD consider the number of tabs the user has open in setting a limit to the number of simultaneous pending connections." That's going to end up being anachronistic. Let's not put SHOULDs on this kind of user interface stuff. How about instead, "For example, in a web browser context, the number of open windows or tabs are a good indication of the number of simultaneous connections." 4.2 - "_This section only applies to servers._" Seems unnecessary. 4.3 - Do you really intend base64-value (and therefore Sec-WebSocket-Key and Sec-WebSocket-Accept) to be able to be empty in the ABNF? 5.5 - "A response to an unsolicited pong is not expected." SHOULD/MUST NOT be sent? 5.7 - I don't think "_This section is non-normative._" is necessary. Further, this section seems oddly out of place. Perhaps in an appendix?
1) At the next to last bullet in the list of fragmentation rules in section 5.4, can you make it clearer that an intermediary that might fragment a frame will always be able to tell that whether or not extensions have been negotiated? In particular, consider calling out that an intermediary that isn't able to see the server's handshake message (due to it being inside a TLS tunnel for example) also would not "see" individual frames, so it wouldn't be possible for it to try to fragment them. If the assumption in my first question isn't true, then a more aggressive adjustment to the text is probably needed. 2) The text in section 5.5.2 (Ping) could be misinterpreted to require sending a Pong even after receiving a Close (otherwise it violates that MUST). 3) There are currently three ways to say this frame has 5 octets of data. Please consider adding a requirement to use the shortest of those three possible ways. (This is related to one of Stephen's discuss points).
<for the Apps ADs> This draft contains a normative reference to IDNA2003. While progressing other drafts through the IESG gauntlet something along the lines of the following was said "referring to IDNA2003 normatively is going to be a show stopper" and "IDNA2008 is the go-forward technology". Has the thinking changed? And, can I use the same magic pixie dust you're using to refer to IDNA2003 when I progress other non-Apps drafts in the future? <process weenie> Shouldn't the RFC 3490 DOWNREF have been called out in the IETF LC? The WGLC on April 24, referred to fixing all IDNITS, but not the downref to RFC 3490. </process weenie> </for the Apps ADs> #1) I'm sure you the WG addressed this, but it would be great if the hash could support something other than SHA-1 for the Sec-WebSocket-Key. I assume you've linked this in some way to the protocol's version # so that websocket++ can support SHA-256, etc. #2) Sec 4.2: Should the ABNF for the frame-rsv* be something like: frame-rsv* = %x0 / %x1 to allow for the possibility of a "1" value? Doesn't the current ABNF only allow "0"?
Sec 1.6, p11, last para: Maybe add a reference to http://www.w3.org/TR/XMLHttpRequest/ so people can find where Sec- headers aren't supposed to be set. Sec 5.2: FIN: whether 0 or 1 indicates the final fragment is in ABNF, but it would help to have it in the prose when the field is first introduced. Sec 14.1: Any reason to not point to FIPS 180-3?
While I agree with Adrian's procedural comments, I believe that the basic idea is sound.
This is a relatively small Discuss. I have already discussed it with Stewart and we think we undertand the intention, but I am entering the whole Discuss point so that the authors can respond... Danny McPherson wrote the following notes in his Routing Directorate review. > I'm still unclear about the proposed publication track for this > document, and the precise objective. If the aim is to deprecate a > feature in TWO Standards Track RFCs (4271 & 5065) shouldn't it be > Standards Track as well and recommend which documents be modified > in what manner? The current recommendation is that operators stop > using a Standards Track feature, and this seems a bit backwards to > me. All this seems to predecated on the statement that this document deprecates AS_SET and AS_CONFED_SET. If that was the case then... Certainly, the document must be updating RFC 4271 and RFC 5065. So I would expect that in the header and the Abstract, and I would expect specific discussion in the body with reference to the sections of those RFCs that are being updated. As to what track this document should be on... I can't get excited, but Danny does seem to be right that Standards Track seems more appropriate. But I think the point is that you are not deprecating anything in the protocol. You are recommending against the use of AS_SET and AS_CONFED_SET. If that is the case: Change "Deprecate" - Document title "Recommendation on non-use of..." - Abstract "This document recommends against the use of..." - Introduction - delete Since this practice is thought to no longer be widely used, it is thought to be safe to deprecate the use of AS_SET. > Regarding the Introduction and "very seldom used" discussed, I've > seen this discussion evolve and because "very seldom used" != 0 it > may be worthwhile to ask either the respective operations communities > and/or upstream network operators, or perhaps the RIRs involved with > the number resources in question, to contact and expressly notify the > current operators that use this feature in order to avoid breaking > operational infrastructure and encouraging them to change their > routing design to remove AS_SETs - or to make a real solid case for > why they cannot. Again, this is a question of whether support is deprecated, or use is NOT RECOMMENDED. If you mean to deprecate from the protocol, then I agree with Danny. If you mean to recommenda against use, then no change is needed.
I would like to see proper use of RFC 2119 language in Section 3 strongly advised == RECOMMENDED should withdraw == SHOULD withdraw operators may begin filtering == MAY --- Section 3 It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / I prefer s/may not/might not/
should this UPDATE something? e.g. RFCs 4271/5065 maybe
I support Adrian's Discuss, and pete's comments. Either this is an update to the existing standards, and thus should be standards-track itself, OR it is a usage recommendation. Either way, the document, especially, the RFC2119 language, should be modified to reflect the purpose.
Paragraph 1 of section 3 has a couple of places that look appropriate for 2119 language: "are strongly advised to not" could easily be "SHOULD NOT" and "should withdraw" could be "SHOULD withdraw". Indeed, the last sentence of section 3 mirrors the language of 2119 where it says "the operator should understand the full implications of the change." So if you really want to use 2119, it seems like these are good places to use it. However, the one (and only one) place you *do* use 2119 language, it is used incorrectly: It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / AS_CONFED_SETs in them, and MAY treat as infeasible routes containing them. Future BGP implementations may also do the same. This is not defining the optional behavior of treating routes as infeasible. This is saying that it should be noted that new technologies might treat routes as infeasible. I suggest changing "MAY" to "may" or "might". If you put SHOULDs into paragraph 1, include the 2119 reference. If you don't, remove the 2119 reference entirely. Either way, fix the MAY.
The DISCUSS and COMMENT is partly based on the OPS-DIR review performed by Benson Schliesser. 1. The claim in the Abstract is confusing. The draft proposes deprecation of usage of AS_SET and AS_CONFED_SET, which seems like a desirable goal. However, the Abstract claims “[t]his is done to simplify the design and implementation of the BGP protocol” but the document offers no specific updates to the BGP protocol. If updates to the BGP protocol are to be done elsewhere, a reference and/or pointer would be welcome. If no specific protocol updates are envisioned at this time, and the document is merely suggesting that operators should cease using these attributes, then this should be made explicit, and maybe a section that recommends further work on the protocol should be added. 2. Being the most significant element of this draft, section 3 needs to include more specific details. Operators that already announce routes with AS_SET or AS_CONFED_SET are advised to re-announce those prefixes without the deprecated attributes, perhaps undoing aggregation and announcing more-specific routes. But it should be made clear under what circumstances the original prefix may continue to be advertised (re-announced), and that in other cases the more- specific routes are advertised instead (not in addition), etc. This draft doesn’t need to provide a primer on Internet routing with BGP, of course, but it should at least give more details and/or pointers on how to implement the recommendation. 3. Further, the draft should explicitly discuss recommendations to operators that receive routes with AS_SET or AS_CONFED_SET. The simplest case is to recommend that these operators continue with status quo. However, the draft mentions “new technologies” that “may not support” these routes, and that “operators may begin filtering routes that contain AS_SETs or AS_CONFED_SETs”. If operators should behave differently as a result of this deprecation, then the recommended behavior should be described. Likewise, if existing technologies and/or implementations should be updated as a result of this deprecation, those updates should be described. The draft doesn’t appear to provide or recommend any specific updates to BGP; that should be explicitly stated.
1. I support comments made by the other ADs about improper use (or lack of use) of 2119 keywords. 2. In the Introduction section, the second paragraph contains a statement that route aggregation “can cause operational issues that include reachability problems and traffic engineering issues”. From an editorial perspective, this statement might be easier to read if broken into two or three sentences. In any case, it would be valuable for this statement to be expanded and/or include a reference to background information. 3. The third paragraph in the Introduction contains a statement that aggregation benefits are “outweighed” by complexity and confusion. The judgment made by this statement feels correct, but likewise an explanation and/or reference would be useful. Additionally, while the [analysis] reference to “Measurement Data...” provides useful details on the number of routes with AS_SET / AS_CONFED_SET attributes, some analysis of the impact on table size would be useful. Specifically, what is the compression ratio achieved by extant AS_SET routes and thusly how might those routes multiply if replaced by more-specific routes? I doubt that it will have a material impact on default-free routing, but it’s worth discussing if any data is available.
I am not sure what this document adds to the RFC series. Before this document was written, if an implementation didn't support IPv6, it wasn't compliant with RFC 2460. Now, if an implementation doesn't support IPv6, it isn't compliant with RFC 2460 or this document. -------------------------------------------------------- The meat of this document is in the bullet list at the bottom of Section 2. The following are comments regarding that bullet list: 1) It is meaningless to levy a new requirement against a "current implementation". The current implementation has already been implemented. It can't change. 2) It is meaningless to say that an implementations IPv6 quality must be better or equal to its IPv4 quality. Since vendors don't produce buggy code intentionally, it would be impossible to control the distribution of bugs among features. ---------------------------------------------------------------- The discussion of how this document updates RFC 1812 is distracting. It should be condensed as follows: RFC 1812 defines requirements for IP Version 4 Routers, but uses the generic terms IP and ICMP. In RFC 1812, the generic terms IP and ICMP should be replaced with the specific terms IPv4 and ICMPv4.
I support the document and it's intent, but would ask the authors to think about the following: These two statements seem contradictory: IPv6 support MUST be equivalent or better in quality and functionality when compared to IPv4 support in an IP implementation. It is expected that many existing devices and implementations will not be able to support IPv6 for one or more valid technical reasons, but for maximum flexibility and compatibility, a best effort SHOULD be made to update existing hardware and software to enable IPv6 support. Do the authors mean in the first para : IPv6 support in NEW equipment and software ....... Also is there any danger that the demand for immediate equivalence will introduce unintended delays in the deployment of more IPv6?
Section 2 says "IP is redefined to mean IPv4 + IPv6", but I think to be consistent with the rest of the document it should say "IP is redefined to mean IPv6 or IPv4+IPv6"?
I think I am missing the point of this document. It is not that I disagree with it, but I don't see what it hopes to achieve. Is it the intention that any node that claims to be "IP-capable" must support IPv6? Will this document achieve that? The statement that a user wants an "Internet caable" device and will not select specifically for IPv6 is fair. But redefining a term that is current usage will not fix this. --- There is a slight contradiction between the language in the abstract where "IP-capable" is redefined to make IPv6 mandatory, and that in Section 2 where you have "SHOULD not support IPv4 only". --- Section 2 It is expected that many existing devices and implementations will not be able to support IPv6 for one or more valid technical reasons, but for maximum flexibility and compatibility, a best effort SHOULD be made to update existing hardware and software to enable IPv6 support. I think "will not be able to" might better read "cannot be updated to" because "will not" conveys a confusing future tense regarding existing implementations. Does the update intend to be made in the field, or for future shipments? Is there a statement here about not continuing to ship existing products?
I think this would make a wonderful "letter to the editor" opinion piece. I would love to ballot "Yes" on this document,m because I share the authors' opinions. But I don't feel I can do that. I have two major issues with the document - one is an editorial concern that can be addressed by the authors; the second is a discuss-discuss. 1) This document uses RFC2119 keywords in a way that I think violates the spirit, if not the requirements, of RFC2119. I think RFC2119 keywords are not really meant to be used for what we wish the industry would do, expressed as MUSTs and SHOULDs. As Ron points out in his reviews, you cannot apply new requirements to existing implementations - they cannot be changed except by developing a new implementation (which might be a modified current implementation). I think my concerns about the RFC2119 usage could be addressed by modifying the text. 2) My real concern is that publishing this document a Proposed Standard RFC might actually be damaging. IPv4 is being exhausted, and will no longer be suitable as *the* IP protocol underlying the Internet. The IETF mission is to make the Internet run better. We have in some ways been amiss in adding on lots of hacks to IPv4, such as NATs, and we are in the process of adding more. I believe that we have now reached a point where we are applying life-sustaining efforts to IPv4 that have exceeded the benefits/cost tradeoff threshold. Many of these hacks make the Internet run worse, not better. I think it may be time to declare IPv4 Historic, and stop trying to save it by piling on more detrimental hacks. We should **rewrite** documents like RFC1122 to reflect IPv6-only or dual stack options, to make it clear that an implementation that only supports IPv4 does not make the Internet run better; By supporting IPv4-only and the needed hacks, these implementations make the Internet run worse. This document is a just a band-aid that might make the authors feel good, like an opinion piece does, but it gives the impression that it might actually accomplish something. I fear the only thing it will accomplish is to delay the work of actually rewriting RFC1122 and other documents to recognize that IPv4-only is no longer adequate for use in the Internet.
I see nothing harmful about this document, but I also don't see that it will have any real-world impact.
1. I support Ron's DISCUSS. 2. I do not understand why this document aims to be a Proposed Standard. There are no testable requirements to allow this document to progress on the standards track. 3. Jouni Korhonen made the following comment in the OPS-DIR review: The I-D is standards track and updates 1812, 1122 & 4084. However, the I-D states: "...Therefore, the above-listed standards are not being updated to include the complete technical details of IPv6, but to identify that a distinction must be made between IPv4 and IPv6 in some places where IP is used generically." I am pointing at this because the current I-D text regarding updates to these specifications is not detailed enough. Just giving few "for example"s is not enough. What I think is needed is a clear (bullet) list of affected sections for each document separately also detailing what is the exact text that gets affected/updated and how. Now too much is left for the reader.. I suggest that this comment is addressed before the document is published.
I don't have any problem with this if the WG and people implementing from it are happy with it, but it does seem that the format as just a collection of the changes rather than a stand-alone document to be possibly confusing and error- prone to work from. However, if the real stakeholders are happy with it, then that's all that matters, I guess.
I have not done a detailed review of this document and will trust that the Security ADs have done. I am somewhat puzzled by... This document contains a new IANA considerations section to be added to [RFC5273] as part of this update. Section 3.2 says... Reference: [ RFC-to-be ]
Doesn't the new change subject name thing require a new security consideration? E.g. if an RA says it'd like a new cert renaming stephen.farrell to *.google.com? I think just a sentence saying that the RA and CA need to ensure that both the new and old names adhere to any relevant policies/practices would do fine. There may be a case for also making the general point as well that CAs MUST check names are according to policy/practice as well, but even if so, the new name change thing should also get a mention I reckon. But that can all be done in one sentence so it should be easy.
Please consider the editorial comments from the Gen-ART Review by Elwyn Davies on 5 September 2011.
Lionel Morand raised a few issues related to backwords compatibility of some of the changes specified in this document. I would like to hear the answers of the document authors and make sure that these aspects were taking into consideration. 1. Update to RFC 5272: - In the section 2.3. (Replace Section 6.3. Linking Identity and POP Information): Three mechanisms are defined for linking identity and POP information: witness value, certificate linking and shared-secret/name matching. In this document, the first two mechanisms MUST be supported by clients and Servers whereas only the Witness value based mechanism was mandatory to support and the certificate based linking was not defined in RFC 5272. This might cause backward compatibility issues with legacy implementation and some text may be required to indicate how to deal with legacy clients/servers. 2. Closed 3. Updates to RFC 5273 - In section 3.1. Update to Section 5 TCP-Based Protocol: A new IANA-registered Port Number is required whereas it was previously possible to use any port number in RFC 5273. Does it mean that any legacy implementation will have to be upgraded to support this new registered Port Number?
1. I believe that this format of defining in one RFC updates for other 3 RFCs is quite difficult to read and follow. 2. - In section 2.5. New Section 6.20 RA Identity Proof Witness control: "Identity Proof Version 2" should be "Identity Proof Version 2 control" if I'm correct.
I concur with Wesley Eddy's comment, especially given the scope of changes to RFC 5272.
I would like to talk about the topic of vulnerabilities of RELOAD's source routing capability. As you know, source routing mechanisms have had serious security problems, for instance problems with the IPv6 routing header type 0 lead to its deprecation in RFC 5095. Section 12.6 of the RELOAD document says: Because the storage security system guarantees (within limits) the integrity of the stored data, routing security focuses on stopping the attacker from performing a DOS attack that misroutes requests in the overlay. There are a few obvious observations to make about this. First, it is easy to ensure that an attacker is at least a valid peer in the Overlay Instance. Second, this is a DOS attack only. Third, if a large percentage of the peers on the Overlay Instance are controlled by the attacker, it is probably impossible to perfectly secure against this. And I agree with these statements. However, I would like to see at least some analysis of the vulnerabilities of your source routing mechanism. You should assume that there can be malicious insiders in an instance. After all, you are talking about P2P networks. How serious are attacks from these devices? What kind of amplification factors might be achieved through an attack?
I have needed to read draft-ietf-p2psip-base at least three times and talked with one of the RAI ADs and a couple of the authors before being is a position to be moderately confident with the intent of this document and the operation of the protocols. I think that the intent is correct and the IETF needs a protocol that does application layer routing. However I am not yet convinced that the design chosen is one that is in the best interests of the Internet, or that the quality of the document is adequate. The RELOAD protocol is a monolithic re-creation of all seven layers of the Internet written using application layer terminology and techniques. It is thus difficult for those familiar with the classic method of describing such protocols to be confident that the text provided is complete, consistent and correct, particularly in the operational corner and pathological cases. RELOAD is a what is known in the lower layers as a layer network. It is regrettable that it does not describe the reason to recursively reuse each of the "classic" Internet protocols without explaining why each was unsuitable. This is doubly so because it is possible that where a "classic" protocol was unsuitable for RELOAD, the corresponding RELOAD component may have been a valuable addition in the "classic" network protocol set. It is somewhat ironic that a protocol designed using applications techniques does not seem to have been designed to be recursive since the sub-IP, IP and Routing layers are commonly used recursively. It is also regrettable that the document is a monolith rather than using the large set of small documents approach that has served us so well in the past in the lower layers. I am concerned that in the long terms this will cause problems with maintaining and extending the protocol. To take routing in particular, this scatted over the document such that the RTG-dir reviewer and myself were concerned that much of the protocol description was missing. I am concerned that structure will make it difficult for implementers to understand all the corner case conditions during coding and test, and harder for the operator community to specify and manage their networks. I am concerned that the document is really not understandable without first understanding the CHORD paper, and further concerned that parts of the CHORD paper are implicitly normative text in the specification. The technique of explaining RELOAD-CHORD as a delta on the CHORD paper makes this particularly problematic. In addition the IETF is not able to make this essential paper directly available to readers, nor to issue and manage errata on it. I am concerned that the only OAM is PING when we have known for years that to manage a router network you need at least traceroute and current interest is in a significantly increased OAM tool set. If the proposal were to publish RELOAD as experimental I would leave the draft to it's fate. However it is a Standards Track Document which means that it has to be sufficiently free standing and with sufficiently normative text that an engineer can implement an interworkable version of the protocol without additional information. Furthermore I am uncomfortable as to whether the document provides sufficient detail that two non-interworking implementations can resolve which is the correct implementation from this specification alone. I would prefer that the document be split into a number of smaller documents: architecture, link connection, routing, transport, OAM etc in the way that is the tradition of lower layers. I suspect that this is not a direction that the authors would wish to take. I realize that the above is not crafted as an actionable Discuss. I propose to discuss this on the call with the IESG, and if no actionable discusses result, or if it is clear that I am alone in this view, I will move the text above to a comment and consider abstaining.
I have a number of detailed comments/nits below. == Bootstrap Node: A network node used by Joining Peers to help Nlocate the Admitting Peer. "Locate," rather than, "Nlocate?" == Routing Table: The set of peers which a node can use to route overlay messages. In general, these peers will all be on the connection table but not vice versa, because some peers will have Attached but not sent updates. I had to read this sentence several times to undersand it --maybe just be more explicit in terms of what could in which table while not being in the other table. ICE is used but not defined Finger table is used before it is described rather than defined, and the description really only becomes meaningful with knowledge of the CHORD paper. Skiplist could do with a reference other than requiring the reader to Google for the definition.
Multi-part DISCUSS, which I think requires a document update (and possibly more discussion, though the email thread between Michael Scharf and Bruce is a great start): (1) Section 18.104.22.168 has a handwave about TFRC and TFRC-SP, however those both require description of how both sender and receiver-side information can be used to compute loss intervals and measure losses, which isn't here, and may not even be necessary here. The section is "retransmission and flow control" but those are both distinct (though coupled) with congestion control, and TFRC answers neither. I don't think the mention of TFRC is even proper and not related to the rest of the section since it's more for applications that are streaming out data at some controlled rate, rather than sending messages and waiting for acknowledgements on them or retransmission events. What's here doesn't seem to relate. (2) As noted by Michael Scharf, the RTO computation text in section 22.214.171.124.1 has a confused (or confusing) citation of RFC 6298 and may lead to instability in presence of RTT variations. (3) During discussion of the tsv-dir review from Michael Scharf, it became evident that some issues are confusing in the split between the functionality for end-to-end message transport across the overlay versus similar functions that exist hop-by-hop in the overlay (e.g. by using TCP). Some cases where this was apparent: - in the section 1.2.5 mention of "reliability, congestion control, flow control, etc" - in the timer discussion around section 5.2.1 - in the discussion of head-of-line blocking around section 126.96.36.199 - in section 5.6.3, throughout the section It would be good for clarity to have some text in the architecture section to describe the envisioned division of labor between the overlay protocol and the underlying (layer-4) transports that are used in the "link" layer and how those relate to the message transport sub-layer of RELOAD, especially since those transports offer different services to the application. Otherwise, problems with nested control loops that exist between layer-4 protocols and various layer-2 technologies can similarly arise in RELOAD use.
- It may be a good idea near the beginning of section 1 to be clear as to whether RELOAD is intended to setup P2P overlays per-application using RELOAD, or to setup a single Internet-wide RELOAD overlay that many applications would commonly utilize. Some of the phrasing later in the section can be interpretted either way, e.g. "The RELOAD network" in 1.1 and "RELOAD is fundamentally an overlay network" implies that there is only one and that it can be what the name RELOAD refers to rather than just the protocol. But, of course, this is inconsistent with what other parts of the same sections imply. I could see some people being confused. The terminology actually clarifies it by defining "overlay instance", but that isn't until section 2. It's worth clarifying early on since there have historically been P2P protocols that were single-network in their operation, and so this vision exists in some heads. - In the figure on page 13, "TLS" and "DTLS" might more appropriately be "TLS/TCP" and "DTLS/UDP" in order to include the actual transport layer protocols themselves. - In section 3.1, there may be some confusion between certificates being given to "nodes" versus "users". The text is clear that there can be multiple nodes serving a single user. It might need to explicitly state whether or not a single node can serve multiple users. For potential integration into systems like ISP caches this distinction may be important to clarify. - Section 3.3 mentions NAT traversal as a routing requirement, but it was previously described in section 1 as being a part of the forwarding sub-layer and not the routing sub-layer. I think that the "routing" in 3.3 encompasses both sub-layers (and maybe more) the way that it's being described there.
So I have a humongous set of discusses and comments on this humongous document. (Probably some of the comments at least are because this is the first time I've read any of this.) But, don't get the wrong idea - I quite like this and hope it becomes an RFC as soon as its ready. Right now though, its not quite ready. (1) section 3.1: Is collision resistance needed for the case where the Node-ID is a digest of the node's public key? How is node key rollover done? Do I loose all stored data? I think you need to make all those clear. (2) section 5.1: Does "correctly formatted" include checking signatures etc? I think you probably mean that it does include signature checking, but you need to say that. (3) section 5.1.1: I assume the list entries here are meant to be mutually exclusive and I'm not meant to do all that apply? Or am I meant to do the first case that applies. Saying that would be good. Does the last bullet need to say "not equal to this node and not the wildcard ID"? (4) cleared (5) section 5.3.4: You say that signatures MUST be checked but don't say how to handle bad signatures. I assume you drop the message? (Since there are no bad-signature error codes defined.) (6) section 188.8.131.52: This doesn't say that the JoinAns MUST come from the peer to which the Join was sent. I think that's needed. (7) section 184.108.40.206: What prevents/detects replay of JoinReq messages? If replay worked, then I could cause lots of havoc since the responding peer will do a bunch of Stores and Updates. (8) section 220.127.116.11: What prevents/detects replay of LeaveReq messages? Seems like an obvious DoS if possible. (9) section 6: is there supposed to be a relationship between the notAfter value from certificates and the sum of storage_time and lifetime? I think you need to say something here as otherwise data could be stored beyond the time at which its signatures are verifiable. I don't mind if you say that cert.notAfter is the max or if you say to ignore cert.notAfter but if you say nothing different implementers are likely to do different things. (10) section 18.104.22.168: I think you need to say whether or not the signatures in the StoredData MUST be checked here. I assume you do want them checked but you don't say. (11) section 22.214.171.124: If the signer's cert has expired, is a signature on a stored value still considered valid or not? One issue is that if any revocation/status checking is supported then there may not be any such information available for expired certs. Another issue is that if you do consider signatures only verifiable with non-expired certs, then a lot can go wrong when a cert expires and its hard to fix that up. I don't have a good solution to offer, but maybe you have an answer? (12) section 7: I don't see how to send a reference to a certificate - 5.3.4 doesn't seem to allow for that now - wouldn't you need a new CertificateType for that? (13) section 10.1: I don't get <shared-secret> - is that mode really well-specified? Seems like you're publishing a shared-secret which isn't really secret then is it? Or did I miss something? Maybe you want to say that configurations that use this MUST NOT be publically available and MUST be locally installed in a trusted way or something like that? (14) section 10.1: You don't say here that the signature(s) MUST verify for the configuration to be used. Neither do you say that the signers MUST chain up to the one of the root-cert values included in the configuration. I think you could justify not requiring that, but then you should say so, so that coder's don't do the wrong thing. (15) section 10.3: Putting the password (or even username) in the query string is not good practice - those can get logged by servers accidentally far too easily. Why don't you define a HTML form that you then POST? (16) section 10.3: might need to warn against dodgy username values, e.g. containing a null character or whatever. I think you need some more rules there to end up with a safe rfc822name in the cert. (Or else have an argument that that's not a problem for RELOAD - it has been a problem elsewhere.) Also, does the enrollment server choose the domain component of the rfc822 name or may that be supplied by the client? (17) section 10.3: What character set is allowed for passwords? What if something is URL escaped - what's going to match? I'm sure you can copy from somewhere else, not quite sure what's best though. (18) section 10.3: You say the signer for this exchange MUST be one of the root-certs from the configuration. I think that that ought say that it MUST be a CA and it MUST chain up to one of the root-certs. Why force the root to be online like that? Or, you could add a new configuration setting for a user-signing-ca-cert and then it'd be ok to say that one of those MUST be used for enrollment. = You could probably say that if this is not a new configuration and has a root-cert that is common with a previous configuration then the outet signature MUST verify and MUST chain up to the previous root-cert. = I think you can say that the kind-signatures MUST verify and MUST chain up to a root-cert from the current configuration. = I think you can say that implementations SHOULD provide a way to allow completely new configurations, or configuration updates with only-new root-certs to be accepted but that that's out of scope. (19) section 13.15: is reg-name sufficiently clear for the overlay name? For example, that allows percent encoding - are those variant names all the same overlay? I guess so, but it'd be good to confirm and maybe say that in the document.
overall: - I've got to say that this reads a lot like an experimental specification. Its so complex and has so many moving parts and ways to plug stuff in, I wonder if its really at the right stage for the standards track. While I'm willing to believe the WG/AD that it is (almost;-) ready, I'm still worried a bit that a whole bunch of things could turn up when its deployed. - The IPR declaration appears to be for something that has (as far as I can see) nothing whatsoever to do with the protocol. Who knows, but the filing seems to be about MIMO, which is a fairly low in the stack thing to be related to an overlay on top of (D)TLS. Wouldn't it be nice if that hadn't happened? - This reminds me of DTNs [rfc4838,rfc5050] but witout the disruption tolerance. Interestingly, if the timer defaults were made to be part of the overlay then it could actually be used for a DTN. I can also imagine that other overlays might benefit from being able to modify the timer defaults either up or down - so would it be worthwhile allowing the overlay config to override or specify those default values? - There's a lot of lowercase occurrences of "must." It'd be great if you could clean that up, e.g. saying if they're meant as RFC 2119 terms or not, e.g. 3.3's 1st few uses of "must" seem like they are 2119 terms, but not all others are, e.g. the last one in 3.2. - A number of the detailed comments below were written as I was reading the document, and relate to stuff that became clear as I read further. If the comments says "but what about <foo>?" and <foo> is explained later on, that means that I didn't get <foo> on first reading to that point. You might want to consider adding some text or a forward reference in some of those cases. I've marked those with (*) in case you want to do that. section 1: - It'd be good to restate the peer/client distinction here (from e.g. the charter) at the very top, e.g. moving the 2nd last para of 1.1 earlier - Can "high performance" be quantified? If not, then is it really a "feature"? - Maybe add a reference to [Chord] in the intro? section 1.1: - "connected graph" assumes always-on? needs to be clear, maybe not a great term (*) I was wondering what the lifecycle of a Node-ID might be. It became clear, but only *much* later. - "also a storage network" - can I store my 24GB of photos using this? if not (as I expect) then that'd be better stated here. section 1.2.2: - maybe clarify that you don't mean cryptographic keys - add a reference for KBR section 2: (*) what's the lifecycle of a Kind-ID? are these also fixed length? (*) what's the "fixed length" of a Node-ID? (*) can a single peer/client instance be part of >1 overlay instance at once? I guess that's just an implementation issue for the peer/client, but wondered if there's anything that'd prevent that or make it hard. - typo: "Nlocate" ? - "Joining Peer" and "Admitting Peer" are those only for peers or clients too? If the latter, then Node would be right I guess? Section 3 seems to imply that node would be more correct here. - Connection Table definition refers to Attach handshakes and Updates but those haven't been introduced yet. Might be better to use natural language rather than those terms at this point if there's an easy way to do that. - Routing Table - the sentence "In general,..." is confusing. You also use "Attached" but haven't yet said what that means. Maybe just say that the routing table is a subset of the connection table if that's the case. (*) Destination List - isn't that a source route? If not, what's different? If so, why not say so? Does it include the IDs through which the message has already been routed or not? Later, (in 5.1.1) I find out that the earlier IDs are dropped, saying that here would be good. And also say that its not just Node-IDs, but also Resource-IDs, that wasn't clear 1st time. - The last paragraph here seems oddly detailed compared to the others - would it be better elsewhere? As-is, there's not enough in this paragraph for the reader to understand this having read to this point so I think moving would be better. (Not sure where yet.) section 3.1: (*) how is the Node-ID included in the cert? (*) what is "the user name found in the certificate"? that wasn't a defined term - shouldn't it be? Where is it in the cert? is there just one user name per cert/user/device? - 3.1.1 is very short and needs references and maybe more. section 3.2: (*) this is the first time that the peer/client distinction and storage have been mentioned together. Are clients allowed to/required to be able to store stuff? - If peers "typically" have "storage responsibilities" does that mean some peers may never store stuff? How can the overlay tell if that's the case and not try store stuff at that peer? - 2nd para here is mostly a repeat. Better to not do that. section 3.2.1: - 2nd para/bullet needs some work. "The client can initiate..." sentence has a few unclear instances of "it" and the following sentence has one too ("to reach it"). - "learnable via other mechanisms" are those specifed? if not, then how will it work interoperably? (*) the text about Node-IDs in certs and Attach/Ping can't be understood at this stage in reading. section 3.2.2: - the list of things a client must (not MUST?) do could really do with cross references to the relevant sections where a coder can find the stuff they need. (*) this says all client (and I guess peer) implementations are overlay-specific, is that right? if so, that seems to break the architecture or does it? section 3.3: - what is "significant state"? - Saying "In all cases, the response...needs to (be) delivered..." seems to be a very hard requirement. Does this protocol really meet that requirement? - Saying "...and not to some other node." is odd. I'm not clear what you really mean. - I guess inverting the via list can fail if the topology has changed. Is this handled? What happens? - This is the 1st occurrence of the term "transaction id." That should be in the terminolgy section really. Who creates these and with what scope (e.g. do they need to be globally unique?) - The figures in 3.3 could do with captions so they can be referenced. (Same is true generally.) - The text says that using a transaction id means not having to change the message, but seems to involve changing the response message. If so, that should be stated. If not, then briefly saying how that works would be good. section 3.4: - This says that 3.2.1 describes a case of a direct connection to an arbitrary IP address, but I didn't see mention of that there. - "need to periodically verify" connections - I assume that's defined later on in detailmentions section 3.5: - typo: using CHORD or Chord consistently would be better section 3.5.2: (*) I assume the cache TTL is specified later - Does caching the set of nodes "it has connected to with public IP addresses" mean a node has to know all the bogons and not cache those or is the mention of "public" here just a reference to the bootstrap phase? (the grammar's not great there either, "nodes to which it has connected" would be better:-) - How is the first-ever-node case handled if the network is temporarily entirely disconnected? Is there a need for a MUST NOT for implementers that are developing "ordinary" nodes or something? Without that, how can the node tell if its really the first one or not? section 3.6: - the term "user" wasn't defined - I think it'd be worth doing that to distinguish it from client/node. section 3.6.1: - What trust anchor is to be used for this HTTPS connection? (And add a reference to 2818 I guess.) - Does the HTTPS connection here need a reference to 6125? If not, then is the overlay name supposed to be in the server cert? If not, then how do I know I've been sent to the right place? - section 3.6.2: - If the config document says who's the trust anchor for the overlay then it probably MUST be gotten securely. But that's not stated. If this is done in the open, then being clear about the leap-of-faith step would be good. I mean saying what's important there, exactly when it happens, what might go wrong etc. That may be later but putting it here (or a forward reference) seems like its needed. section 4.1 (*) Signatures imply some c14n rule, esp if supporting array/dictionary. Is this covered? section 4.2: - the list could do with forward references to places where these items are detailed. - Didn't it say earlier that Resource-ID=hash(name) was just an example? - "...after a network partition." Do you mean "...after a network partition is healed"? In any case that paragraph confuses me. This is also the first mention of time sync, so a bit more introductory text seems needed. section 5.1: - This is the 1st mention of the wildcard Node-ID, that should go in section 2 as well and needs definition. I guess its like an anycast and not a multicast, unless the overlay does some kind of message replication. section 5.1.1: - This is the 1st time that I figured out that a Resource-ID could be on a destination list. That should be stated in section 2 which doesn't make that clear. - The 2nd bullet says forward the thing but makes no mention of the Via field. Isn't that needed? (5.1.2 does mention it.) section 5.1.2: - It seems odd to have the middle case in presentation order say "if neither of the other ... apply" since I've not yet read 5.1.3. Maybe re-order the sections? - Should that say "neither of the other *two* cases"? 5.1 only has 3 bullets and "neither...three..." would be odd. Or am I missing even more than usual;-) - "likely to be responsible" is very wooly, as is "consults" the routing table. - Why is it a SHOULD for the case where the 1st entry is on the connection table? Didn't you define the routing table just to make this distinction? If the SHOULD is right, then what's the exception? - "This may be arranged in one of two ways..." and then you have two MAY statements. There's a MUST missing here. - The transaction ID example seems to have node C (or A or B) create the transaction ID and not node D. That should be stated. (I assume its really the initiator who creates it.) - Saying "It MAY either be a compressed..." is a bit confusing. I guess those aren't the only options? (I could encrypt the list to make a private ID if I wanted, right?) - What is "FORWARD_CRITICAL"? This seems like an odd place to introduce the 3 second timer. section 5.2: - If alternative routing can be selected on a per-message basis and a node doesn't support that routing scheme, then what does it do? Drop the message or use the MTI scheme? Or is this embedded in the overlay name/ID? section 5.3.2: - Is the overlay name that is hashed into the overlay 32 bit value case (in)sensitive or just treated as octets? If SRV records are used bootstrapping for this I guess something may need to be said about this. - "MUST be randomly generated" - it'd be good to give guidance here about PRNGs, e.g. maybe cite 4086? - You don't say where to put a new entry in the via_list. I assume its at the end furthest from the start of the message. section 126.96.36.199 - compressed_id was earlier called private ID - why change? section 188.8.131.52 - the struct has flags before length but the descriptions are length and then flags. But the length desription says "...rest of the structure" which could be interpreted to include the flags field. I guess it oughtn't and just moving the length description should fix this. Also saying the option value is "length" bytes would be good and giving an exanple of how to handle length==0 would help too. section 5.3.3: - The criticial field in extensions has proved to be slightly problematic in X.509 over the years. The debate arises now and then as to what "understand the message" means, with some saying just knowing the type means you understand it, others saying you need to be able to do all processing defined for the extension type and some in between. It would be good to be more specific here about what "understand the message" means, for example saying that any relevant MUSTs and SHOULDs are supported or something like that. I'm happy to remove this discuss point as soon as I'm told the WG thought about this and its ok as-is, but wanted to check. section 184.108.40.206 - error_info is a UTF-8 string unless otherwise stated. Is this intended for human consumption or not? If so, then how are language issues to be handled? - I'm not clear as to whether the error_info for the various error_code values is expected to be as described here. For example, if the error is Error_Forbidden, does the description of that imply something about what goes into error_info or not? - typo: Error_Data_Too_old is repeated. section 5.3.4: - might be no harm to also say that the NodeID in H(NodeID || certificate) MUST be in network byte order? Saying "simple raw bytes" could cause endian-issues there. - This says that "receiving nodes" MUST verify the signature. Earlier it said that nodes just need to check formatting (in 5.1). That seems to be a conflict. See also discuss point (2). - I don't get how the first additional check works if the response has a via - I thought that that meant that the nodes on the path for the response didn't need state? If so, then how does the verifier here know who originated the request to which this is a response? - The 2nd additional check is a bit unclear for me. It says that response-sender-node-ID MUST be as close or closer to the resource-id in the *requesting node's* neighbour table. How does a verifier in the middle of the path get to see the requesting node's neighbour table? section 5.4.1: - Has anyone specified a topology plugin other than the MTI one from here? I'm wondering if the list here is really complete and doable. (It'd be easy to get this wrong.) section 220.127.116.11: - Which error SHOULD nodes sent if they cannot form connections? section 18.104.22.168: - Is the "no more aggressive than TFRC" sentence here clear? section 6.1: - given that the StoredDataValue can be up to 4GB would it be better to put the SignerIdentity before that in the signature input? That might help the verifier go quicker in the case of LARGE data values I guess. section 6.2: - Is 2^32-1 octets really expected to be supported here? Might there be a case for distinguishing small (say up to N KB) from larger data values? (Just checking) section 6.2.3: - it'd be no harm to say what you get when a non-existent dictionary key is used in a query, as you did in 6.2.2 for arrays. section 22.214.171.124: - this introduces the "anonymous" and "none" values for SignatureAndHashAlgorithm on page 88. That really needs to be introduced where signing is first discussed and you need to say when its allowed to be used and for what. (In this part you just say it cannot be used.) section 126.96.36.199: - "(unlike previous versions)" - if there's nothing you can reference then I'd suggest taking this out - it might have been useful for the WG but might just confuse the RFC reader. section 188.8.131.52: - I don't get the last sentence - how does the requester ask for the user's cert? And should that say owner's cert? (That may be just due to how long it's taken me to read this, at multiple sittings;-) section 8: - You should probably add a reference for the "private address range" and think about whether or not the putative new private allocation counts there too. (It may be that getting this document finished takes long enough that that process is done.) section 9.7: - You RECOMMEND that a peer maintain O(log(N)) things in the neighbour set. I'm not clear how the peer knows the value of N there? section 10.1 - This is not right! Why not use a real <signature> in the example? If the example could be verified that'd help coders. - You might say is ascii-hex values can be mixed case or not. Be a shame to fall over because of that and coders might make different assumptions. - Why are we not using XMLDSIG for the signatures here? (Only kidding:-) section 10.2 - s/by determines/by determining/ - Isn't RFC6125 a better reference here than 2818? - Does this practically mean that overlays should be named using DNS names? If so, saying that early would be good rather than on p124. - s/such an/such as an/ section 10.3: - Does the enrollment server web server cert have to have any relationship with the configuration? I don't think that's needed, but am not sure. It'd be good to say either way though. - Using HTTP errors is fairly coarse grained. In particular don't you want to have a way to say "everything's fine but you asked for too many nodeids"? If there's a good HTTP error for that then calling it out would be good. Just a bare 4xx for username/password errors is fine though. section 12: - Do you need to reference the TLS re-negotiation bug RFC? Would it have a bad impact here? (Not sure.) section 13.5 - I don't get why you have two SIP entries there. It'd be nice to know.
The Gen-ART Review by Mary Barnes on 9-August-2011 points out significant inconsistencies in the document. Please resolve these inconsistencies. Please consider the other comments as well; Mary offers very helpful suggestions. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg06582.html.
3.1 - The concept of "user" appears in this section along with "username", but it never really gets defined, or for that matter is understandable at all, until 6.3. Some introduction to "user" might be nice somewhere at or before 3.1. 5.1.1 - If a wildcard Node_ID is used, does the does the message get sent to the Message Transport for forwarding? Not spelled out in this section. 184.108.40.206 - Editing error: Error_Data_Too_Old is followed by Error_Data_Too_Old 5.3.4 - No discussion of wildcard in this section. Does there need to be? 5.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 5.5 (and maybe sections 5.6 and 8) is not a separate document.
This document being the principal specification that defines a new protocol I was expecting to find information concerning operational and manageability considerations. A separate document (draft-ietf-p2psip-diagnostics) defines extensions to the base protocol for diagnostic purposes, and this is fine. However that document is not referred here and there is zero information about how the protocol will be deployed in existing networks, what is the impact on traffic and requirements from hosts, routers, midcom devices (if any), what is the operational model and how is the RELOAD protocol managed in deployments, any hooks for manageability in the software, any defaults for initial configuration, alarm conditions, monitoring of performance.
I'd like to talk about several points that I haven't seen mentioned in other reviews. 1. Section 1.3 appears to couple issuance of certificates and assignment of Node-IDs (in most cases): RELOAD's security model is based on each node having one or more public key certificates. In general, these certificates will be assigned by a central server which also assigns Node-IDs, although self-signed certificates can be used in closed networks. What is the reason for this coupling? Does it have security implications? At the least, a forward reference to later sections (e.g., 3.1) might help. 2. Does the use of list compression (Section 5.1.2) and private IDs (Section 5.1.3) prevent an intermediate node from routing return messages if its neighbor goes offline? In your example, if E has a destination list of (D, I) but D goes offline, then E won't be able to unpack the private ID "I" to recover the via list "(A, B, C)". 3. In Section 10.1, the format of the 'expiration' attribute is not fully specified (e.g., are timezone offsets allowed or must the datetime be UTC?). 4. Section 10.1 states that "The configuration file is a binary file and cannot be changed - including whitespace changes - or the signature will break." The XML file doesn't look very binary to me! But if you require special formatting then please specify it, for example by saying that "the configuration file MUST NOT include any whitespace as separators between XML elements" or somesuch. 5. In Section 10.3, placing the username and password in the clear as URL parameters seems a bit dodgy even if SSL/TLS is used, since URLs can be copied or can otherwise leak out.
1. Regarding communication security, Section 1.3 states: Message Level: Each RELOAD message must be signed. Object Level: Stored objects must be signed by the creating peer. Did you mean "MUST" instead of "must"? 2. In Section 3.1.1, please provide references for TLS-PSK and TLS-SRP. 3. In Section 3.2.1, please provide a reference for TURN. 4. In Section 3.2.1, forward references would help for Attach (Section 5.1.1), Ping (5.5.3), Destination List (220.127.116.11), etc. 5. Section 3.2.2 mentions "the topology plugin required to act as a peer in the overlay"; does this assume a plugin architecture for Node implementations? Perhaps not, because in Section 5.4 the spec talks about a "Topology Plugin" in a more generic sense. It might be good to clarify. 6. The description of symmetric recursive routing in Section 3.3 makes me wonder whether messages themselves are stored at the nodes in the Via list; if so, does that introduce possible concerns related to privacy, security, and auditing? 7. Please expand "ICE" on first use (Section 1) and in Section 3.4. 8. Section 3.6.1 states that "the node does a DNS SRV lookup on the overlay name to get the address of a configuration server"; a forward reference to Section 10.2 would be appropriate here. Also, a reference to RFC 2782 seems in order here. 9. Section 3.6.2 states that "the enrollment server's ability to restrict attackers' access to certificates in the overlay is one of the cornerstones of RELOAD's security"; by "access" seems to be meant "privilege to be granted its own certificate", not "capacity to know the certificates of other nodes". 10. Section 4.1.1 states that "only a user with a certificate for 'firstname.lastname@example.org' could write to that location in the overlay". At least a forward reference to Section 10.3 would help, which is the only place where the user name is a define as an rfc822Name (at least in the certificate). Furthermore, it would help to more clearly specify how a user name prepared and compared for authorization purposes. 11. In Section 5.1, what exactly does it mean for a peer to "pass a message up to the upper layers"? 12. Is there a reason why the end-to-end reliability mechanism in Section 5.2.1 doesn't recommend exponential backoff on retries? 13. Section 5.3.2 states that "transaction IDs ... MUST be randomly generated"; perhaps a reference to RFC 4086 is in order? 14. In Section 18.104.22.168, it would be good to state whether the "error_info" text is intended to be presented to users (if so, we might need language tagging). 15. In Section 5.3.4, what exactly is "the identity used to form the signature"? It appears to be a Node-ID (or a hash thereof), but it would be good to make that clear in the definition (e.g., could it also be a Resource-ID)? 16. In Section 22.214.171.124, are "srflx", "prflx", and "relay" as defined for Candidate Types in ICE? The "type" is said to "correspond to the cand-type production" but it might help to point a bit more directly to RFC 5245. 17. Section 126.96.36.199 mentions previous versions of RELOAD. Given that no references are provided, is that mention helpful? 18. The <self-signed-permitted/> element is of type xsd:boolean; please note that this datatype has two lexical representations, "1" or "true" for the concept true and "0" or "false" for the concept false. You might want to point this out to implementers. The same applies to the other elements with a datatype of xsd:boolean (no-ice, clients-permitted, etc.). 19. Section 10.1 does not clearly specify which elements and attributes are required and which are optional. Is it assumed that the reader needs to refer to the schema for this information? 20. In Section 12.3, it might be worthwhile to mention the possibility of attacks against the central enrollment authority. 21. In Section 13.6, it's still not clear what it means for an XML format to be binary-encoded. I think this needs to be more clearly specified, then the registration can reference the appropriate section of the spec.
(updated to capture config-chord and to make the comments easier to read.) The document does not appear to register the namespaces urn:ietf:params:xml:ns:p2p:config-base and urn:ietf:params:xml:ns:p2p:config- chord? The definition of the fragment field in 5.3.2 (page 43) should be updated to reflect the design choices that resulted in the high bit always being set (as called out at the end of section 5.7). The definition here implies that the high-bit might not be 1 in a valid message. I'm not finding specific normative text that describes how an implementation is handles a message that has an incorrect version number. The first part of 5.1 talks about "can process" and an "appropriate error", but leaves a lot of room for interpretation on what those mean. Can this be made more explicit? Section 3.2.1 has a 2119 MUST, but this section is intentionally non-normative.
Page 38 - Section 5.2.1 - might be worth calling out that the sending node will be doing both e2e and hopbyhop retransmissions Page 48 - Section 5.3.3 - should note 0x8000-0xfffe are reserved Page 82 - Section 6 - Can you find a different word than "unpartitioning" (or define it)? - it only occurs once in the document. Page 107 - the formula at the end of 9.5 has unbalanced parentheses Page 112 - In the implementer note in 188.8.131.52, can you point to references to get the implementer started?
nit - Introduction "This document proposes several changes " should presumably be "This document makes several changes " I am concerned about the following: "Note that the distinct requirement from RFC 2026  for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations." We really need to consider defining "independent". NTP is a good illustration of the problem - there are lots of boxes out here that run NTP which some may perceive as independent implementations. However they all seem to run the code written by Dave Mills' project arguably making them a single implementation. Since we touching on the subject we should clarify what we mean by "independent" give the existence of open source.
Thank you for addressing my earlier DISCUSS and COMMENT issues. It looks to me as though there is still a bit of redundancy in section 2.2. Do these two paragraphs refer to the same IETF-wide Last Call? The criteria for advancing from Proposed Standard to Internet Standard are confirmed by the IESG in an IETF-wide Last Call of at least four weeks. The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are: [...] After review and consideration of significant errata, the IESG will perform an IETF-wide Last Call of at least four weeks on the requested reclassification. If there is consensus for reclassification, the RFC will be reclassified without publication of a new RFC.
I'm changing to Yes on this based on the recent mails to ietf-discuss. I continue to think there is rough consensus for 2 levels but am motivated to move to a Yes by the arguments of those against moving to 2 levels which appear to me indistinguishable from obfuscation. (Which could be deliberate or a side-effect of some honestly held opinion, its not really possible to say.) This is such a boring topic that a funny quote seems worthwhile: “A Frenchman once tried to obfuscate me from behind. Although I protested out of sheer principle, I must confess that I thoroughly enjoyed it.” ~ Oscar Wilde on Obfuscation I think the always-reliable Oscar's quote is as relevant as the objections to 2 levels that I've seen so far. My original comment was: I still don't know from reading this if STD numbers will be allocated for "Internet Standard" RFCs. I don't mind if they are or not, but confusion about it doesn't seem good. For example, what'll happen to ?  http://www.rfc-editor.org/rfcxx00.html#STDbySTD
I agree fully with Peter's DISCUSS. He summarized much better than I could have. I do believe that there probably *is* agreement on the requirement changes to move from Proposed to whatever is the next level and that these changes do address a problem by lowering the burden of moving out of Proposed. I would like to see those adopted, independent of agreement on the other two portions (i.e., returning to a lower bar for Proposed, or removing one level of the standards track).
Section 2 contains the following: Experience with a Proposed Standard often leads to revisions that clarify, modify, enhance, or remove features. Review of revisions to a Proposed Standard that is submitted for publication at the same maturity level is generally limited to the changes. Perhaps r/the changes/these types of changes ? RFC 5967 already updates RFC 2026, but a reference to RFC 2026 in Section 2.2 would be helpful to those writing implementation reports.
This is a great document, thank you for writing it. I will vote Yes as soon as the following issues are clarified: The document says: However, there are network drivers that fail to pass the Interface Identifier to the stack and instead synthesize their own Interface Identifier (usually a MAC address equivalent). If the UE skips the Duplicate Address Detection (DAD) or has other issues with the Neighbor Discovery Protocol (see Section 5.4), then there is a small theoretical chance that the UE configures exactly the same link-local address as the GGSN/PDN-GW. The address collision may then cause issues in the IP connectivity. This is true, except that I am not sure about the part that issues in IP connectivity may arise. The global prefix is not used by the GGSN at all (this is guaranteed in the specs), so the only issue could be in the use of link local addresses. What kind of problems have you seen with this? Since there are no services with a GGSN, its hard to see what actual traffic might be impacted. Local use of link locals with other devices on the same connection could be impacted, of course, you would think that the terminal would use a different address if it was unable to allocate a link local address. Or if it did not get a problem in allocating such an address, the communication would be local and the collision would be undetected. Please expand on what the failure mode is here. Currently several operating systems and their network drivers can make the 3GPP PDP Context to appear as an IEEE802 interface/link to the IP stack. This has few known issues, especially when the IP stack is made to believe the underlying link has link-layer addresses. First, the Neighbor Advertisement sent by a GGSN as a response to an address resolution triggered Neighbor Solicitation may not contain a Target Link-Layer address option (as suggested in [RFC4861] Section 4.4). Then it is possible that the address resolution never completes when the UE tries to resolve the link- layer address of the GGSN, thus stalling all IPv6 traffic. Second, the GGSN may simply discard all address resolution triggered Neighbor Solicitation messages (as hinted in [RFC3316] Section 2.4.1 that address resolution and next-hop determination are not needed). As a result the address resolution never completes when the UE tries to resolve the link-layer address of the GGSN, thus stalling all IPv6 traffic. I don't think there is anything that we can really do on the GGSN side about this. Since there are no link layer addresses, it would be bad to insert them in the messages. It seems that the reasonable implementation approach would be to have the layer that simulates a 802 network fake the necessary addresses and address resolution messages. If you agree, can you say so? Currently it seems that you may be saying RFC 3316 should be changed. If you mean that instead, please say so clearly.
I have no objection to the publication of this document. --- I find myself in agreement with Stephen. the document reads well, but having gone to the trouble to write this guide, I think you could have taken it one step further and described the security issues as well (not that I have a clue what they are, but that is why I would find the description helpful). --- Section 1 OLD There are many factors that can be attributed to the lack of IPv6 deployment in 3GPP networks. NEW The lack of IPv6 deployment in 3GPP networks can be attributed to many factors.
- While I agree that this document doesn't *introduce* any security related concerns, neither does it tell the reader about any, which is a real pity. Are the authors saying that there are no security (or privacy) concerns about 3GPP's use of IPv6, nor any new issues that need(ed) addressing? That seems unlikely. Or, are the authors saying that no-one deploys any security for IPv6 in 3GPP - which would be perhaps more believable but even more unfortunate. In either case, I'd have expected more than one sentence. Other than the above, I quite liked this, (at least... more than any 3GPP thing I've read before:-) and think it could be very useful. - SGSN and GGSN are used in the intro before the terminology section, an English phrase for what they do might be better there, e.g. "various gateways" might do it. - 2.2: many APNs have various IPv4 addresses and username/pwd pairs that are publicly known. I don't know if there's any IPv6 information associated with publicly known APNs (or that ought to be) but if there were that might be of interest. I thought I might see something about that in 8.4 as well but didn't, or at least I didn't get it, if its there. typo spotting: - HSS definition: s/got introduced/was introduced/ - 8.3: s/in order the roaming/in order for the roaming/
I had the exact same thought about the security considerations that Stephen had.
1) References to draft-ietf-lisp and draft-ietf-lisp-ms should be normative, not informative. If the referenbced drafts change radically, the sense of draft- ietf-lisp-lig may change. 2) It is not clear what needs to be standardized. All of the bits requiring interoperability are defined in the referenced drafts. 3 )There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 4) There are 24 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 5735 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x.
1) The reference to LISP-LIG seems to be self-referential. 2) The reference to draft-ietfr-lisp-alt-06 does not resolve
Responding to Joel Halpern's question about Informational vs. Experimental: I prefer Informational and would not object to Experimental.
Updated Discuss after exchanges with the document shepherd. Most material moved into the Comment (hoping that the authors will still address it). I expect the remaining Discuss issue to be resolved by the IESG on the telechat. --- I am having trouble with this document. I can't work out what there is to implement for interoperability. I suppose a stretch would be to say that user-level interop would be achieved by all implementations of a tool for inspecting the mapping database having the same command structure. That would reduce the document to some of the text in 4.2. It is not that I think the document is harmful, it is just that I don't understand why it is WG Experimental output. Maybe if I had seen it as Informational I would have been more inclined to accept it. Maybe if it had come as independent. Anyway, this is not a big, blocking Discuss. I would just genuinely like to discuss it to hear what the thinking was in the WG so we can make sure we do the right thing.
Section 1 s/IDS/IDs/ --- Section 2 s/an destination/a destination/ --- Section 3 Verifying registration is called "ligging yourself". Surely this is "groping yourself"? --- Please add a note somewhere to explain to the reader of this document that the DB is public. I.e. be precise on the fact that the DB is the set of publicly available LISP resolvers. --- Section 8 Please add a sentence stating that LIG can be misused hence the importance to protect LISP-MS and support security features.
- I guess the definitions here aren't meant to be authoritative if they conflicted with e.g. another of the WG's documents. It might be no harm to just say that and point at the document that will have the authoritative definitions just in case. (The UDP port number included here is what triggered this, I guess there's an outside chance that might change for some reason as some other document progresses.) - Some ascii-art would be helpful if the authors had the time and energy, but that might be better in some other draft (or maybe exists elsewhere). - PTR is used but not defined. - Is it right to say "EID address"? There're a couple of those. typos: s/an destination/a destination/ s/an a address block/address blocks/ s/usage cases/use cases/ s/each which/each of which/
Please consider the comments from the Gen-ART Review by Mary Barnes on 10-August-2011. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg06586.html.
I agree with Adrian's DISCUSS. I don't see how this is an Experimental document. Looks Informational to me.
I actually liked the way this document is written, the fact that it describes an operational tool, that it is based on implementation experience and deals how the tool is deployed and used. Very little documents nowadays include this type of information. I somehow must agree with other ADs that the document looks more like Informational than Experimental. True that (all?) other LISP documents are Experimental, but this is not an automatic license to make Experimental a document that would never make it on the standards track and does not describe any new interoperability element. If the document is to stay Experimental I suggest that information is added about what are the goals and expected results of the experiment.
I support Ron's DISCUSS item about the need for Normative References. The document cannot be read and understood without reading those.
s 10.2: r/draft-ietfr-lisp-alt/draft-ietf-lisp-alt
Please consider the suggestion from the Gen-ART Review by Brian Carpenter on 2-Sept-2011: One tiny piece of future-proofing would be to state that in this context, 'ogf' stands for 'open grid format'. Thus, if the OGF ever changes its name (as it has in the past) or even, unthinkably, vanishes, the namespace would still make sense.
There seem to be a couple of syntax issues in this text: OLD: The base Proxy Mobile IPv6 [RFC5213] all though required the use of a fixed link-local and a fixed layer-layer address, NEW: Although the base Proxy Mobile IPv6 [RFC5213] requires the use of a fixed link-local and a fixed link-layer address,
I think this is a useful document. It seems like it should have "Updates: RFC 5213" though?
Section 1 To address this problem, this specification makes the following two reservations. The mobility elements in the Proxy Mobile IPv6 domain MAY choose to use these fixed addresses. Stumbled over this because it looks like the second sentnece is a reservation (i.e. a modification to the base spec), but there is only one reservation listed.
Strike section 2.1. 2119 is not used in this document.
In general, it is extremely good that we have documents like this. Thank you for doing this work! I have not dug in deep enough to understand the details and whether all the measurements make sense, but I think we should encourage both this document and other similar ones to be published. Thomas Clausen has been showing some measurement results (incidentally with somewhat different conclusions) and I think we should ask him to publish his results also as a similar RFC. As well as others who have data. I also believe that the RFC Editor stream is a good place to put this type of publications. The one high-level comment that I have is that we should be very careful about conclusions from these types of measurements in the resulting RFCs. Its a natural tendency for people to make generic conclusions when most of the results apply to a specific scenario that they measured, not everything. You also have to be very careful in making system-level applicability statements based on single-packet level performance (e.g., 99% packet reliability => system reliability is good -- I don't know if that's the case or not. We'd have to do the math to really understand if 99% is good or bad). I think the authors, the RFC Editor, and the IESG should all check to make sure there are no too wide ranging conclusions in documents like this. Finally, I did have some reactions to this specific document. Please consider them as improvement suggestions. It is of particular importance that we pay attention to various conclusions about the good or bad operation of a given IETF technology, as noted above. ---- Section 3 seems to say that nodes send 80% of their traffic to root, but I can't find a statement that says something about the root sending traffic back to the nodes. I think in most realistic cases there will also be acknowledgments. Am I just missing the text that explains the return traffic, or did you not simulate the return traffic at all? Section 4.3 states that as 90% of nodes are capable of operating under 10 routing table entries, then the protocol is capable of working in constrained nodes. I do not think this can be inferred. If 10% of my nodes have to store significantly larger routing tables (and those nodes are not the root or some other conveniently a priori known device), its not going to help. I still have to deploy more memory to every node. Section 4.4 should make a similar conclusion about the satisfaction of the latency requirements. Again, if 99% of communications are timely, it may not help satisfy requirements of industrial installations, for instance. The requirements are usually stated as, say, no communication failures within a period of time (say, a month or even a year) that could not be handled with the used reliability mechanisms. These mechanisms could include, for instance, repeated transmissions, acknowledgments, or transmissions to duplicate destinations. If a single packet reliability is 99%, what's the likelihood of the a communications problem in an N device system with communication event frequency F and, say, triple transmissions to ensure reliability? You need to do the math to provide an evaluation of whether 99% is good or bad.
Picking up from Peter's point I also started to review text version and realized that there must be a pdf version. Many readers will not know this and will not know how to get the pdf version. They would be better served if a note directing them to read the pdf version was provided at the beginning of the document. Indeed the RFC editor may be spared considerable work by making the text version of the document simply the abstract and a pointer to the pdf. I note that there is no security section to the document. Is this not also mandatory in the independent stream?
I have reviewed this document in accordance with RFC 5742 and am making the following recommendation to the IESG as a response to be sent to the ISE. The IESG will formally decide on their response on 8th September 2011. The IESG has concluded that this work is related to IETF work done in the ROLL WG, but this relationship does not prevent publishing ========= Editorial Comments. These comments are provided for the information of the authors and ISE. --- It would be considerably helpful if the document included text explaining the absence of the figures, giving a URL for the PDF, and resolving any issues of discrepency between the text and PDF files. --- Section 1 is not clear on the difference between a hop metric and a transmission metric. Naifly, one might assume that a pcacket is transmitted exactly once per hop on the path. --- The reference to RFC 2119 seems inappropriate in this document. --- You will want to note that draft-ietf-roll-trickle has been published as RFC 6206
- Luckily, I read the PDF. I agree with the comments that noting its existence in the ascii would be good. - Documents such as this are always much more valuable (IMO) if the underlying simulation code and data can be made available for others. I don't know if that's possible here or has been done, but if so, a link from which those could be downloaded would be a great addition. - Figure 1 has two colours for links but doesn't say why. - I didn't get the spike to the right in figure 9 - it'd be no harm to say why that's there for (I guess) node 38. The scaling on that figure could also be better, the control traffic is hardly visible - a logarithmic scale would be clearer. - 1st para of 5.2 is repeated. - 1st para of 5.2 is repeated.
As this document defines metrics and used them for performance evaluation of ROLL, should not IPPM and BMWG also b ementioned in the IESG note?
The PDF version makes for interesting reading. Unfortunately, the ASCII version is considerably less valuable because so much of the text makes reference to graphical aspects that are available only in the PDF version.
We should let this document be published. That being said, I do have a number of comments that are perhaps best directed to the RFC Editor and the authors. >and it reduces the number anti-replay window is adjusted. This text does not parse. > For high-end multi-core network > processor with multiple crypto cores, a window size bigger than 64 or > 128 is need due to the varied IPsec processing latency caused by > different cores. I think it is a very bad idea to use implementation strategies that cause significant packet reordering. In particular, the interoperability implications towards implementations (many) that happen to employ 32 or 64 bit windows... not to mention impacts to higher layer protocols. In my opinion, the document needs to describe its interoperability implications. I'm not sure if the IESG needs to require that or if that's just something that the RFC Editor should ask the authors to do, but this obviously has an affect to the ability of an implementation to work with another one. > In such a case, the window sliding is tremendous > costly even with hardware acceleration to do the bit shifting. Really? In an implementation that has to run complex cryptographic operations on each word in the packet? I can imagine hardware solutions where bit shifting is really easy :-) In any case, isn't this just an example of the use of good old circular buffers (http://en.wikipedia.org/wiki/Circular_buffer)? Elements in the buffer are bits indicating whether or not the sequence number has been seen, and in addition to the circular buffer pointers you have to keep a value that indicates what the first (or last) sequence number in the window is. Then you check for a packet that has been seen with seqno >= windowstart && seqno <= windowstart + WINDOW_SIZE - 1 && circbuffer->table[circbuffer->first + (seqno - windowstart) % WINDOW_SIZE] Or something along those lines. Is this all you are doing, or am I missing something? If so, I found the description in the body of the document unnecessarily complicated.
- Should this have the vendor name in the title? That'd be the "Futurewei IPsec anti-replay..." - last sentence of abstract is unclear - I'm not sure what's being reduced. - intro, 2nd sentence: s/The mechanisms/The mechanism/ - introp, last para: s/For high-end/For a high-end/ s/is need/is needed/ - I don't get this: "We hide one block from the window." Probably just needs re-phrasing.