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.)

Corrections from:

1 Administrivia

  1. Roll Call 1133 EDT:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Runtime LMA Assignment Support for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netext-redirect-10
    Token: Jari Arkko
    Note: Rajeev Koodli (rkoodli@cisco.com) is the document shepherd.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-netext-redirect-03
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-netext-redirect-07
    Discusses/comments (from ballot 3752):
    1. Ralph Droms: Comment [2011-09-07]:
      I've cleared my DISCUSS. Thanks for addressing my DISCUSS and COMMENT issues in my previous review.
    2. Wesley Eddy: Comment [2011-07-02]:
      (blank)
    3. Adrian Farrel: Discuss [2011-09-05]:
      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.
    4. Adrian Farrel: Comment [2011-09-05]:
      Thank you for fixing my earlier Comment
    5. Stephen Farrell: Comment [2011-08-22]:
      (blank)
    6. Russ Housley: Discuss [2011-09-03]:
      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.
    7. Russ Housley: Comment [2011-04-21]:
      Please consider the minor and editorial comments from the Gen-ART Review by Pete McCann on 14-Apr-2011.
    8. Dan Romascanu: Comment [2011-04-28]:
      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'?
    9. Robert Sparks: Comment [2011-09-06]:
      (blank)

    Telechat:

  2. The WebSocket protocol (Proposed Standard)
    draft-ietf-hybi-thewebsocketprotocol-13
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3862):
    1. Ron Bonica: Comment [2011-09-05]:
      A couple of reference issues..
    2. Wesley Eddy: Discuss [2011-09-06]:
      (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.
    3. Wesley Eddy: Comment [2011-09-06]:
      In section 4.2.2, is the "might" really a MAY or is it a SHOULD?
    4. Stephen Farrell: Discuss [2011-09-05]:
      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 [1] 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.
      [1] http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pdf
      (10) I think the last call comments about the traffic profile [2] 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.
      [2] http://www.ietf.org/mail-archive/web/ietf/current/msg69148.html
    5. Stephen Farrell: Comment [2011-09-05]:
      (ten items plus typos)
    6. Russ Housley: Discuss [2011-09-03]:
      The Gen-ART Review by Richard Barnes was updated to cover the -13 version of this document...
      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.
    7. Pete Resnick: Comment [2011-09-07]:
      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?
    8. Robert Sparks: Comment [2011-09-06]:
      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).
    9. Sean Turner: Discuss [2011-09-07]:
      <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"?
    10. Sean Turner: Comment [2011-09-07]:
      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?

    Telechat:

  3. Deprecation of the use of BGP AS_SET, AS_CONFED_SET. (BCP)
    draft-ietf-idr-deprecate-as-sets-05
    Token: Stewart Bryant
    Note: John Scudder (jgs@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3888):
    1. Ron Bonica: Comment [2011-09-05]:
      While I agree with Adrian's procedural comments, I believe that the basic idea is sound.
    2. Adrian Farrel: Discuss [2011-09-04]:
      This is a relatively small Discuss. I have already discussed it with Stewart and we think we understand 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 recommend against use, then no change is needed.
    3. Adrian Farrel: Comment [2011-09-04]:
      I would like to see proper use of RFC 2119 language in Section 3...
    4. Stephen Farrell: Comment [2011-09-02]:
      should this UPDATE something? e.g. RFCs 4271/5065 maybe
    5. David Harrington: Comment [2011-09-07]:
      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.
    6. Pete Resnick: Comment [2011-09-04]:
      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.
    7. Dan Romascanu: Discuss [2011-09-08]:
      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.
    8. Dan Romascanu: Comment [2011-09-08]:
      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.

    Telechat:

  4. IPv6 Support Required for all IP-capable nodes (Proposed Standard)
    draft-ietf-intarea-ipv6-required-01
    Token: Jari Arkko
    Note: Julien Laganier (julien.ietf@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3891):
    1. Ron Bonica: Discuss [2011-09-05]:
      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."
    2. Ron Bonica: Comment [2011-09-05]:
      (blank)
    3. Stewart Bryant: Comment [2011-09-03]:
      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?
    4. Wesley Eddy: Comment [2011-09-06]:
      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"?
    5. Adrian Farrel: Comment [2011-09-04]:
      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?
    6. David Harrington: Discuss [2011-09-07]:
      I think this would make a wonderful "letter to the editor" opinion piece. I would love to ballot "Yes" on this document, 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.
    7. Pete Resnick: Comment [2011-09-04]:
      I see nothing harmful about this document, but I also don't see that it will have any real-world impact.
    8. Dan Romascanu: Comment [2011-09-07]:
      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.

    Telechat:

  5. Certificate Management over CMS (CMC) Updates (Proposed Standard)
    draft-ietf-pkix-rfc5272-bis-07
    Token: Sean Turner
    Note: Stephen Kent (kent@bbn.com) is the document shepherd.
    Discusses/comments (from ballot 3926):
    1. Wesley Eddy: Comment [2011-09-01]:
      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.
    2. Adrian Farrel: Comment [2011-09-05]:
      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 ]" ...and I assume that means *this* document.
      So the new IANA section is as a result of 5273, but not part of it.
    3. Stephen Farrell: Comment [2011-09-06]:
      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.
    4. Russ Housley: Comment [2011-09-06]:
      Please consider the editorial comments from the Gen-ART Review by Elwyn Davies on 5 September 2011.
    5. Dan Romascanu: Discuss [2011-09-08]:
      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. Update to RFC 5272:
      - In section 2.6. New Section 6.21 Response Body Control
      "The Response Body Control is designed to enable an RA to inform an EE that there is an embedded response message that MUST be processed as part of the processing of this message."
      This a new feature compared to RFC 5272. Does the RA need to know that EE supports this feature before using it? Or is it assumed that the whole system support the same version of the RFC? Maybe some text would be required here also.
      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?
    6. Dan Romascanu: Comment [2011-09-08]:
      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.
    7. Peter Saint-Andre: Comment [2011-09-06]:
      I concur with Wesley Eddy's comment, especially given the scope of changes to RFC 5272.

    Telechat:

2.1.2 Returning Items

  1. REsource LOcation And Discovery (RELOAD) Base Protocol (Proposed Standard)
    draft-ietf-p2psip-base-18
    Token: Gonzalo Camarillo
    Note: David Bryan (dbryan@ethernot.org) is the document shepherd.
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-p2psip-base-03
    Discusses/comments (from ballot 3884):
    1. Jari Arkko: Discuss [2011-08-24]:
      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?
    2. Stewart Bryant: Discuss [2011-09-07]:
      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.
    3. Stewart Bryant: Comment [2011-09-07]:
      I have a number of detailed comments/nits ...
    4. Wesley Eddy: Discuss [2011-09-06]:
      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 5.6.3.1 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 5.6.3.1.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 5.5.1.6
      - 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.
    5. Wesley Eddy: Comment [2011-09-06]:
      (four items)
    6. Stephen Farrell: Discuss [2011-09-05]:
      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.
      (19 items, more or less...)
    7. Stephen Farrell: Comment [2011-09-02]:
      (many items)
    8. Russ Housley: Discuss [2011-09-03]:
      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.
    9. Pete Resnick: Comment [2011-09-06]:
      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.
      5.3.3.1 - 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.
    10. Dan Romascanu: Discuss [2011-09-08]:
      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.
    11. Peter Saint-Andre: Discuss [2011-09-07]:
      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.
    12. Peter Saint-Andre: Comment [2011-09-07]:
      (21 items)
    13. Robert Sparks: Discuss [2011-09-07]:
      (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.
    14. Robert Sparks: Comment [2011-09-07]:
      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 9.7.4.3, can you point to references to get the implementer started?

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. Reducing the Standards Track to Two Maturity Levels (BCP)
    draft-housley-two-maturity-levels-09
    Token: Jari Arkko
    Note: Russ Housley (housley@vigilsec.com) is the document shepherd.
    Discusses/comments (from ballot 3804):
    1. Stewart Bryant: Comment [2011-06-22]:
      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 [1] 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.
    2. Ralph Droms: Comment [2011-09-07]:
      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..."
      "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."
    3. Stephen Farrell: Comment [2011-09-02]:
      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"
    4. Pete Resnick: Discuss [2011-06-08]:
      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).
    5. Sean Turner: Comment [2011-06-07]:
      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.

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. IPv6 in 3GPP Evolved Packet System (Informational)
    draft-ietf-v6ops-3gpp-eps-05
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com), v6ops co-chair is the document shepherd.
    Discusses/comments (from ballot 3869):
    1. Jari Arkko: Discuss [2011-09-08]:
      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.
    2. Adrian Farrel: Comment [2011-08-23]:
      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.
    3. Stephen Farrell: Comment [2011-08-22]:
      - 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/
    4. Sean Turner: Comment [2011-08-24]:
      I had the exact same thought about the security considerations that Stephen had.

    Telechat:

  2. LISP Internet Groper (LIG) (Experimental)
    draft-ietf-lisp-lig-05
    Token: Jari Arkko
    Note: Luigi Iannone <luigi@net.t-labs.tu-berlin.de> is the document shepherd.
    Discusses/comments (from ballot 3908):
    1. Ron Bonica: Discuss [2011-09-06]:
      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.
    2. Ron Bonica: Comment [2011-09-06]:
      1) The reference to LISP-LIG seems to be self-referential.
      2) The reference to draft-ietfr-lisp-alt-06 does not resolve
    3. Ralph Droms: Comment [2011-09-07]:
      Responding to Joel Halpern's question about Informational vs. Experimental:
      I prefer Informational and would not object to Experimental.
    4. Adrian Farrel: Discuss [2011-09-08]:
      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.
    5. Adrian Farrel: Comment [2011-09-08]:
      (five items)
    6. Stephen Farrell: Comment [2011-09-05]:
      (four items plus typos)
    7. Russ Housley: Comment [2011-09-03]:
      Please consider the comments from the Gen-ART Review by Mary Barnes on 10-August-2011.
    8. Pete Resnick: Comment [2011-09-07]:
      I agree with Adrian's DISCUSS. I don't see how this is an Experimental document. Looks Informational to me.
    9. Dan Romascanu: Discuss [2011-09-08]:
      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.
    10. Dan Romascanu: Comment [2011-09-08]:
      I support Ron's DISCUSS item about the need for Normative References. The document cannot be read and understood without reading those.
    11. Sean Turner: Comment [2011-09-06]:
      s 10.2: r/draft-ietfr-lisp-alt/draft-ietf-lisp-alt

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. A URN Namespace for the Open Grid Forum (OGF) (Informational)
    draft-dijkstra-urn-ogf-06
    Token: Peter Saint-Andre
    Note: The reference [GFD-C.XXX] has not yet been assigned a number within the OGF's standards process. It is now under OGF standards council review. Then it will need to undergo a 60-day public comment period, and an OGF standards council final call. The RFC Editor will be instructed to hold publication until the relevant OGF specification has been published.
    Discusses/comments (from ballot 3895):
    1. Russ Housley: Comment [2011-09-03]:
      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.

    Telechat:

  2. Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 (Informational)
    draft-gundavelli-v6ops-pmipv6-address-reservations-02
    Token: Jari Arkko
    Discusses/comments (from ballot 3904):
    1. Ralph Droms: Comment [2011-09-07]:
      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,
    2. Wesley Eddy: Comment [2011-08-30]:
      I think this is a useful document. It seems like it should have "Updates: RFC 5213" though?
    3. Adrian Farrel: Comment [2011-09-06]:
      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.
    4. Pete Resnick: Comment [2011-09-05]:
      Strike section 2.1. 2119 is not used in this document.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Performance Evaluation of Routing Protocol for Low Power and Lossy Networks (RPL) (Informational)
    draft-tripathi-roll-rpl-simulation-07
    Token: Adrian Farrel
    Note: ISE Submission
    Discusses/comments (from ballot 3935):
    1. Jari Arkko: Comment [2011-09-07]:
      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.
    2. Stewart Bryant: Comment [2011-09-03]:
      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?
    3. Adrian Farrel: Comment [2011-09-05]:
      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
    4. Stephen Farrell: Comment [2011-09-05]:
      - 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.
    5. Dan Romascanu: Discuss [2011-09-08]:
      As this document defines metrics and used them for performance evaluation of ROLL, should not IPPM and BMWG also be mentioned in the IESG note?
    6. Peter Saint-Andre: Comment [2011-08-31]:
      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.

    Telechat:

  2. IPsec anti-replay algorithm without bit-shifting (Informational)
    draft-zhang-ipsecme-anti-replay-03
    Token: Sean Turner
    Note: ISE Submission
    IPR: IBM Corporation's Statement about IPR related to draft-zhang-ipsecme-anti-replay-01
    Discusses/comments (from ballot 3936):
    1. Jari Arkko: Comment [2011-09-07]:
      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.
    2. Stephen Farrell: Comment [2011-09-06]:
      - 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.

    Telechat:

1255 EDT break

1300 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Javascript Object Signing and Encryption (jose)
    Token: Sean

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Layer 2 Virtual Private Networks (l2vpn)
    Token: Stewart

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Definition of Specification Required (Peter Saint-Andre)

    Telechat:

  2. IETF 82 Meeting Schedule for Friday (Russ Housley)

    Telechat:

7. Agenda Working Group News

1336 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-09-08 07:28:13 PDT)

draft-ietf-netext-redirect

  1. Ralph Droms: Comment [2011-09-07]:
    I've cleared my DISCUSS.  Thanks for addressing my DISCUSS and COMMENT issues in
    my previous review.
  2. Wesley Eddy: Comment [2011-07-02]:
    
        
  3. Adrian Farrel: Discuss [2011-09-05]:
        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. 
        
  4. Adrian Farrel: Comment [2011-09-05]:
    Thank you for fixing my earlier Comment
  5. Stephen Farrell: Comment [2011-08-22]:
    
        
  6. Russ Housley: Discuss [2011-09-03]:
        
      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. 
        
  7. Russ Housley: Comment [2011-04-21]:
      Please consider the minor and editorial comments from the Gen-ART
      Review by Pete McCann on 14-Apr-2011.
    
  8. Dan Romascanu: Comment [2011-04-28]:
    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'?
  9. Robert Sparks: Comment [2011-09-06]:
    
      

draft-ietf-hybi-thewebsocketprotocol

  1. Ron Bonica: Comment [2011-09-05]:
    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)
    
  2. Wesley Eddy: Discuss [2011-09-06]:
        (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. 
        
  3. Wesley Eddy: Comment [2011-09-06]:
    In section 4.2.2, is the "might" really a MAY or is it a SHOULD?
  4. Stephen Farrell: Discuss [2011-09-05]:
        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 [1] 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.
    
       [1] http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-
    jackson.pdf
    
    (10) I think the last call comments about the traffic profile [2]
    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. 
    
       [2] http://www.ietf.org/mail-archive/web/ietf/current/msg69148.html
     
        
  5. Stephen Farrell: Comment [2011-09-05]:
    - 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/
    
  6. Russ Housley: Discuss [2011-09-03]:
        
      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. 
        
  7. Pete Resnick: Comment [2011-09-07]:
    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?
  8. Robert Sparks: Comment [2011-09-06]:
    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).
  9. Sean Turner: Discuss [2011-09-07]:
        <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"? 
        
  10. Sean Turner: Comment [2011-09-07]:
    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?

draft-ietf-idr-deprecate-as-sets

  1. Ron Bonica: Comment [2011-09-05]:
    While I agree with Adrian's procedural comments, I believe that the basic idea
    is sound.
  2. Adrian Farrel: Discuss [2011-09-04]:
        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. 
        
  3. Adrian Farrel: Comment [2011-09-04]:
    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/
  4. Stephen Farrell: Comment [2011-09-02]:
    should this UPDATE something? e.g. RFCs 4271/5065 maybe
  5. David Harrington: Comment [2011-09-07]:
    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.
  6. Pete Resnick: Comment [2011-09-04]:
    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.
  7. Dan Romascanu: Discuss [2011-09-08]:
        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. 
        
  8. Dan Romascanu: Comment [2011-09-08]:
    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.

draft-ietf-intarea-ipv6-required

  1. Ron Bonica: Discuss [2011-09-05]:
        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. 
        
  2. Ron Bonica: Comment [2011-09-05]:
    
        
  3. Stewart Bryant: Comment [2011-09-03]:
    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?
  4. Wesley Eddy: Comment [2011-09-06]:
    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"?
  5. Adrian Farrel: Comment [2011-09-04]:
    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?
  6. David Harrington: Discuss [2011-09-07]:
        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. 
        
  7. Pete Resnick: Comment [2011-09-04]:
    I see nothing harmful about this document, but I also don't see that it will
    have any real-world impact.
  8. Dan Romascanu: Comment [2011-09-07]:
    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. 

draft-ietf-pkix-rfc5272-bis

  1. Wesley Eddy: Comment [2011-09-01]:
    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.
  2. Adrian Farrel: Comment [2011-09-05]:
    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 ]
        
  3. ...and I assume that means *this* document. So the new IANA section is as a result of 5273, but not part of it.
  4. Stephen Farrell: Comment [2011-09-06]:
    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.
  5. Russ Housley: Comment [2011-09-06]:
      Please consider the editorial comments from the Gen-ART Review by
      Elwyn Davies on 5 September 2011.
  6. Dan Romascanu: Discuss [2011-09-08]:
        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? 
        
  7. Dan Romascanu: Comment [2011-09-08]:
    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.
  8. Peter Saint-Andre: Comment [2011-09-06]:
    I concur with Wesley Eddy's comment, especially given the scope of changes to
    RFC 5272.

draft-ietf-p2psip-base

  1. Jari Arkko: Discuss [2011-08-24]:
        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? 
        
  2. Stewart Bryant: Discuss [2011-09-07]:
        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. 
        
  3. Stewart Bryant: Comment [2011-09-07]:
    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.
    
    
  4. Wesley Eddy: Discuss [2011-09-06]:
        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 5.6.3.1 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 5.6.3.1.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 5.5.1.6
    - 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. 
        
  5. Wesley Eddy: Comment [2011-09-06]:
    - 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.
  6. Stephen Farrell: Discuss [2011-09-05]:
        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 5.4.2.1: 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 5.4.2.1: 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 5.4.2.2: 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 6.4.2.2: 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 6.4.2.2:  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. 
        
  7. Stephen Farrell: Comment [2011-09-02]:
    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 5.3.2.2
    
    - compressed_id was earlier called private ID - why change?
    
    section 5.3.2.3
    
    - 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 5.3.3.1
    
    - 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 5.4.2.1:
    
    - Which error SHOULD nodes sent if they cannot form connections?
    
    section 5.6.3.1:
    
    - 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 6.4.1.1:
    
    - 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 6.4.1.3:
    
    - "(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 6.4.2.1:
    
    - 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.
    
  8. Russ Housley: Discuss [2011-09-03]:
        
      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. 
        
  9. Pete Resnick: Comment [2011-09-06]:
    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.
    
    5.3.3.1 - 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.
  10. Dan Romascanu: Discuss [2011-09-08]:
        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. 
        
  11. Peter Saint-Andre: Discuss [2011-09-07]:
        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.
     
        
  12. Peter Saint-Andre: Comment [2011-09-07]:
    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 (5.3.2.2), 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
    'alice@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 5.3.3.1, 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 5.5.1.1, 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 6.4.1.3 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.
    
  13. Robert Sparks: Discuss [2011-09-07]:
        (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. 
        
  14. Robert Sparks: Comment [2011-09-07]:
    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 9.7.4.3, can you point to references to
    get the implementer started?
    
    

draft-housley-two-maturity-levels

  1. Stewart Bryant: Comment [2011-06-22]:
    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 [1] 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.
  2. Ralph Droms: Comment [2011-09-07]:
    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.
  3. Stephen Farrell: Comment [2011-09-02]:
    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 [1]?
    
       [1] http://www.rfc-editor.org/rfcxx00.html#STDbySTD
    
    
  4. Pete Resnick: Discuss [2011-06-08]:
        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). 
        
  5. Sean Turner: Comment [2011-06-07]:
    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.

draft-ietf-v6ops-3gpp-eps

  1. Jari Arkko: Discuss [2011-09-08]:
        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. 
        
  2. Adrian Farrel: Comment [2011-08-23]:
    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.
    
  3. Stephen Farrell: Comment [2011-08-22]:
    - 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/
    
  4. Sean Turner: Comment [2011-08-24]:
    I had the exact same thought about the security considerations that Stephen had.

draft-ietf-lisp-lig

  1. Ron Bonica: Discuss [2011-09-06]:
        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. 
        
  2. Ron Bonica: Comment [2011-09-06]:
    1) The reference to LISP-LIG seems to be self-referential. 
    
    2) The reference to draft-ietfr-lisp-alt-06 does not resolve
  3. Ralph Droms: Comment [2011-09-07]:
    Responding to Joel Halpern's question about Informational vs. Experimental:
    
    I prefer Informational and would not object to Experimental.
  4. Adrian Farrel: Discuss [2011-09-08]:
        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. 
        
  5. Adrian Farrel: Comment [2011-09-08]:
    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.
  6. Stephen Farrell: Comment [2011-09-05]:
    - 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/
    
  7. Russ Housley: Comment [2011-09-03]:
      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.
  8. Pete Resnick: Comment [2011-09-07]:
    I agree with Adrian's DISCUSS. I don't see how this is an Experimental document.
    Looks Informational to me.
  9. Dan Romascanu: Discuss [2011-09-08]:
        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. 
        
  10. Dan Romascanu: Comment [2011-09-08]:
    I support Ron's DISCUSS item about the need for Normative References. The
    document cannot be read and understood without reading those.
  11. Sean Turner: Comment [2011-09-06]:
    s 10.2: r/draft-ietfr-lisp-alt/draft-ietf-lisp-alt

draft-dijkstra-urn-ogf

  1. Russ Housley: Comment [2011-09-03]:
      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.

draft-gundavelli-v6ops-pmipv6-address-reservations

  1. Ralph Droms: Comment [2011-09-07]:
    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,
  2. Wesley Eddy: Comment [2011-08-30]:
    I think this is a useful document.  It seems like it should have "Updates: RFC
    5213" though?
  3. Adrian Farrel: Comment [2011-09-06]:
    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.
  4. Pete Resnick: Comment [2011-09-05]:
    Strike section 2.1. 2119 is not used in this document.

draft-tripathi-roll-rpl-simulation

  1. Jari Arkko: Comment [2011-09-07]:
    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.
  2. Stewart Bryant: Comment [2011-09-03]:
    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?
  3. Adrian Farrel: Comment [2011-09-05]:
    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
    
  4. Stephen Farrell: Comment [2011-09-05]:
    - 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. 
    
  5. Dan Romascanu: Discuss [2011-09-08]:
        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? 
        
  6. Peter Saint-Andre: Comment [2011-08-31]:
    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.

draft-zhang-ipsecme-anti-replay

  1. Jari Arkko: Comment [2011-09-07]:
    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.
  2. Stephen Farrell: Comment [2011-09-06]:
    - 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.