IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-01-06. These are not an official record of the meeting.

Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)

Corrections from: Dan

1 Administrivia

  1. Roll Call 1134 EST Amy:
  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. OCSP Algorithm Agility (Proposed Standard)
    draft-ietf-pkix-ocspagility-09
    Token: Tim Polk
    Note: Stephen Kent <kent@bbn.com> is the document shepherd
    Discusses/comments (from ballot 3388):
    1. Jari Arkko: Discuss [2011-01-04]:
      "...A responder SHOULD always apply the lowest numbered selection mechanism that is known, supported, and that meets the responder's criteria for cryptographic algorithm strength."
      I am confused by the last sentence and how it uses the words "selection mechanism". Does this sentence talk about algorithms or the above selection methods? But the selection methods do not have an algorithmic strength, nor are they negotiated. Suggested replacement text:
      "A responder SHOULD always apply the lowest numbered selecetion mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength."
    2. Adrian Farrel: Discuss [2011-01-05]:
      I find a small discrepency at the end of Section 4
      "The server SHOULD use one of the preferred signature algorithms for signing OCSP responses to the requesting client."
      This means (I think) that the server MAY use an algarithm not listed by the client as preferred. You need to cover:
      - under what circumstances
      - what expectations of success it will have
      But, in fact, I think the whole of Section 5 is dedicated to the question of how to select a suitable algorithm, and that means that this sentence in Section 4 needs to be replaced with:
      "Section 5 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client."
    3. Adrian Farrel: Comment [2011-01-05]:
      The RFC Editor will ask you to remove the citation from the Abstract.
      acronyms are used without expansion.
      Section 5.1: Did you think of splitting option 5 into:
      5. select a mandatory algorithm
      6. select a recommended algorithm
      since there is a very marked difference in the likelihood of success.
    4. Alexey Melnikov: Comment [2011-01-04]:
      In Section 4: "The client MUST support each of the specified preferred signature algorithms and the client MUST specify the algorithms in the order of preference."
      I think this is not actually saying what the order is. I suggest adding something like
      "from the most preferred to the least preferred"
      8.3. Denial of Service Attack: "Algorithm agility mechanisms defined in this document introduces a slightly increased attack surface for Denial of Service attacks where the client request is altered to require algorithms that are not supported by the server, alternatively does not match pre-generated responses."
      The last part (after the final comma) is not readable.
      [NEWASN] - is this a Downref?... is [NEWASN] in the Downref registry?
    5. Peter Saint-Andre: Comment [2011-01-05]:
      1. Section 8.1 uses the phrases "considered unacceptably insecure" and "not considered acceptably secure". Are these equivalent?
      2. In Section 8.3, please consider citing RFC 4732 on the concept of denial of service attacks.
    6. Sean Turner: Comment [2011-01-04]:
      I am going to recuse myself from this draft because I was involved in proposing the ASN.1 structure. I don't consider that an insignificant contribution. I am however happy with this draft.

    Telechat:

  2. HTTP State Management Mechanism (Proposed Standard)
    draft-ietf-httpstate-cookie-20
    Token: Peter Saint-Andre
    Note: Jeff Hodges (chair of the HTTPSTATE WG) is the document shepherd.
    Discusses/comments (from ballot 3438):
    1. Jari Arkko: Comment [2011-01-03]:
      I agree with the Discusses from Alexey, Robert, Tim, and for the most part with Sean. I do not agree with the Discuss from Adrian. Obviously the document can make those actions.
    2. Adrian Farrel: Comment [2010-12-13]:
      Section 1: Please don't be so timid.
      Section 10.2: "[Netscape]"
      1. Are you sure this is the best version of the spec? The document is headed: "Preliminary Specification - Use with caution"
      2. RFC Erratum 1491 reads... Can you confirm that you do not need to add a "copy available" statement to this document?
      Erratum 2644 seems to have been submitted after the date of your I-D. I assume that this Erratum will be rejected as soon as your I-D becomes an RFC.
      Section 2.1: "..." Do you really mean "performant" which my dictionary gives only as a noun meaning " a perforemer".
    3. Alexey Melnikov: Discuss [2010-12-20]:
      [Updated as per -20]
      This is a well written document. I am contemplating voting Yes on this document once my issues (see below) are discussed/resolved, not because Cookies are pretty, but because this is the best attempt to describe them properly.
      7) In Section 5.4: "..." Clients can't assume that an arbitrary sequence of octets generated by the server would be a valid UTF-8. This needs to be clarified.
      9) From Lisa Dusseault's Apps Area Review:
      Section 3. "Origin servers can send a Set-Cookie response header with any response.". Do we happen to know if it's more common for user agents to handle, or ignore Set-Cookie response headers on error responses?
    4. Alexey Melnikov: Comment [2010-12-20]:
      5.1.1. Dates: "year = 1*4DIGIT ( non-digit *OCTET )"
      Do people really use 1 digit and 3 digit years?
    5. Tim Polk: Discuss [2011-01-06]:
      This discuss was motivated in part by Richard Barnes' Gen-ART review. Richard noted that:
      "Many of these integrity issues are caused by user agents accepting cookies from outside the context where they would send them, in particular with the Secure and Path attributes. It seems like this document, in specifying the desired/proper behavior of user agents, should require behavior that would mitigate these attacks. In direct parallel to the handling of the Domain attribute:
      "1. Set-Cookies with the Secure flag should only be accepted over secure channels
      "2. Set-Cookies with the Path attribute set should only be accepted if the path value matches the request-uri of the request (That is, update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10)"
      The author responded:
      "I agree that these would be desirable changes to the cookie protocol. However, the http-state working group is not chartered to change the cookie protocol. In particular, the charter reads as follows: "The working group must not introduce any new syntax or new semantics not already in common use." "
      I understand that this document cannot impose new rules or syntax. However, as written this document appears to *prohibit* clients from extending the algorithm to protect themselves: User agents are required to implement algorithms "equivalent to" the algorithms specified in Section 5 to process dates (section 5.1.1), paths (5.1.4), parse a set cookie string (Section 5.2), and the processing the cookie (Section 5.3, which was at the heart of Richard's issues), processing the cookie header (section 5.4), etc. This does not leave an implementer with any wiggle room, forcing them to accept insecure processing rules.
      This document should not prohibit clients from doing additional processing to enhance their own security, especially since the processing rules proposed by Richard apparently would not affect interoperability with a well-behaved server.
      I believe that a better model is the PKIX path validation processing algorithm, where "functionally equivalent" implementations are required but are explicitly permitted to extend the model to enhance security. For example, some implementers have chosen to require that a certificate and CRL be signed by the same cryptographic key to guard against name collisions. This is not required by PKIX but implementations that include this feature are still compliant.
      Is there a good reason why extensions to the user agent's processing cannot be extended as Richard suggested?
    6. Tim Polk: Comment [2010-12-16]:
      I found the following Note at the end of 4.1.1 confusing: "NOTE: Some user agents represent dates using 32-bit UNIX time_t values. Some of these user agents might contain bugs that cause them to process dates after the year 2038 incorrectly."
      After considering this for a while, I concluded that the point is that user agents might convert the dates into UNIX time_t values for storage and processing, and implementation bugs mean that dates after 2038 are not interpreted correctly. If that is correct, then maybe the following would be an appropriate substitution: ...
    7. Robert Sparks: Discuss [2010-12-14]:
      In 4.1.1 (Syntax) - Why is the specification part of this proposed standard allowing implementations to violate the grammar defined by this standard?...
    8. Robert Sparks: Comment [2010-12-14]:
      Please consider moving the SHOULD in the first of the two NOTE:s at the end of 4.1.1 out of the NOTE.
      Consider noting in the discussion of "public suffixes" that the problems this mechanism attempts to avoid are still present in deeper heirarchies (A server at math.example.edu will be able to set cookies for example.edu, potentially affecting the behavior of infosec.example.edu)
    9. Sean Turner: Discuss [2010-12-16]:
      [These are my preliminary discusses. I might find more later.]
      #1) I'd like to see a new security consideration section that addresses persistent cookies. I think we need to mention how expiry date can be abused. Is there some kind of recommendation we can give on their lifetimes? Are cookies good for 2, 5, 20 years okay?
      #2) I'd like to see a new privacy|security consideration that says what's being touted as "private browsing" doesn't protect cookies it only stops the history from being updated.
      #3) Section 7.1: I understand it's hard to have one policy for third-party cookies. But, couldn't we say that assuming sites aren't behaving badly or somehow otherwise sharing tracking data that users that wish to not be tracked by third-parties ensure that third-party cookies be blocked?
      #4) Section 7.2: It's not a protocol thing, but should we really make the following two SHOULDs:
      User agents should provide users with a mechanism for managing the cookies stored in the cookie store.
      User agents should provide users with a mechanism for disabling cookies.
      #5) Section 8.3/8.5: Should point out that the format for signature/encryption is server specific.
      #6) Section 8.3, last paragraph:
      a) The last paragraph, I believe, discusses "sidejacking" and "cookie monster" attacks (or is that the 1st paragraph in 8.5?). Is it worth explicitly mentioning the name of these attacks?
      b) To that end, can we add something like (I'm not wed to the words) the following to the end of the paragraph in 8.3:...
      #7) Sec 8: Where would we say something about how when multiple users use the same machine, they're not protected from one another?
      #8) Sec 8: Shouldn't we have a section on cross-site scripting attacks (i.e., scripts that make browser send cookies to malicious servers that should not receive them) and how http-only helps? I.e., servers should set httpOnly to stop these?
      #9) Sec 4.2/8 ?: Where are cookie poising attack discussed (i.e., client returns a different cookie than the one set by the server)?
    10. Sean Turner: Comment [2010-12-16]:
      #1) Section 4: It's odd that following is in Section 4, which is titled Server Requirements: "User agents, however, MUST implement the requirements in Section 5 to ensure interoperability with servers making use of the full semantics."
      Shouldn't it be in Section 5?
      #2) In Section 5.2, add "(see Section 7.1)" to the end of: "For example, the user agent might wish to block responses to "third-party" requests from setting cookies."
      #3) In Section 5.4, add "(see Section 7.1)" to the end of: "For example, the user agent might wish to block sending cookies during "third-party" requests."

    Telechat:

  3. PIM Group-to-RP Mapping (Proposed Standard)
    draft-ietf-pim-group-rp-mapping-08
    Token: Adrian Farrel
    Note: Mike McBride is the document shepherd (mmcbride@cisco.com).
    Discusses/comments (from ballot 3536):
    1. Adrian Farrel: Comment [2010-12-31]:
      Routing Area Directorate review by Dimitri Papadimitriou raises a few very minor editorial points that should be looked at together with any other comments and issues raised during IESG review.
    2. Tim Polk: Discuss [2011-01-05]:
      This is a pretty straightforward discuss, and should be easy to clear. As noted in Vincent Roca's security directorate review, the document would benefit from some expansion of the security considerations. In particular, some pointers to mechanisms for learning group-to-rp mappings that satisfy the constraint are considered secure would be helpful. Please use Vincent's review as an input to your revisions.
    3. Dan Romascanu: Discuss [2011-01-04]:
      The issue of the relation between this document and RFC 5060 was raised by Adrian with the MIB Doctors. At the end of the discussion which prompted to various methods of altering the behavior of the routers that already support the MIB module the resolution communicated by Adrian was: 'we have decided that we do NOT want to update the semantics of the existing objects'.
      I am still to be convinced that this is the case.
      7. Interpretation of MIB Objects: "..."
      First, in RFC 5060 the 'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects are in two different tables - pimGroupMappingTable and pimStaticRPTable. Each of the table has a different 'precedence' object and a different behavior.
      Does pimStaticRPTable has any function with the new RP mapping algorithm? In RFC 5060 it is used to define static entries that may precede and override those defined by the algorithm in 5060. Does this apply also to the algorithm defined here?
      What does exactly mean 'the usage of these fields will decline'? All the MIB module defined in RFC 5060 is supported ('we do not want to update the semantics') - so what happens with the pimGroupMappingTable? Section 8 describes how objects in this table will continue to be used to indicate Group-to-RP mapping. Whay I am missing is what happenss if a manager creates a new entry as per RFC 5060? Should the router just ignore it? We cannot assume all managers are 'well-bahaved' and we need to prevent I think mis-configuration.
      If the writeable part of the of this table is not disabled, this would be a serious security problem, as it would interfere with the works of the new algorithm.
      A proper solution should include an update of RFC 5060, including changes in MODULE-COMPLIANCE and possibly a new read-only table that would help the operators read the entries created as result of the application of the new mechanism. I understand that the authors and WG do not plan to do this in the near future, but they need to define a clear and acceptable behavior of the agents runing RFC 5060. Dully obsoleting RFC 5060 (and the usage of the MIB module defined there) would be another solution at this point, but this is not what the WG wants, as I understand.
    4. Dan Romascanu: Comment [2011-01-04]:
      1. Section 5: "A network management station can determine the RP for a specific group in a specific router by running this algorithm on the Group-to-RP mapping table fetched using SNMP MIB objects."
      MIB objects are meant to work not only with SNMP. Please change 'SNMP MIB objects' to 'SMI MIB objects' or just 'MIB objects'.
      2. Need to expand MIB and SNMP at first occurence.
    5. Peter Saint-Andre: Discuss [2011-01-05]:
      This is a fine document. However, the algorithm does not specify rules for determining which hash value or IP address is "highest", which might inhibit interoperability. Please specify such rules (e.g., convert to "network byte order" octet string representation and then apply i;octet collation from RFC 4790), or refer to specifications that define such rules.

    Telechat:

  4. The Trickle Algorithm (Proposed Standard)
    draft-ietf-roll-trickle-07
    Token: Adrian Farrel
    Note: JP Vasseur (jpv@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3545):
    1. Stewart Bryant: Discuss [2010-12-15]:
      "All that matters is that some nodes communicate with one another at some nonzero rate."
      This is not right. If every node received, nothing would get communicated. In addition I tend to think of communication as requiring some degree transmission. I think that you mean transmits at some nonzero rate.
      Considering that later text says that Trickle breaks if there is a parameter mismatch, I am concerned that this text is not strict enough:
      "It is RECOMMENDED that a protocol which uses Trickle includes mechanisms to inform nodes of configuration parameters at runtime. However, it is not always possible to do so."
      I am also concerned with the get out clause that allows the degradation of a MUST to a RECOMMENDATION. Surely for the cost of a few bytes the parameters can at least be announced so that other nodes can get some hint that the mismatch is occurring.
    2. Ralph Droms: Comment [2010-12-14]:
      Nit: 3rd para of section 3, s/their/its/
      Question: is the typical value of k in the range 1-5 independent of the density of the network nodes, where I'm thinking of "density" as the number of nodes that hear a given message?
    3. Lars Eggert: Discuss [2010-12-16]:
      I'm sorry for deferring this document to the next telechat. I want the TSV directorate to review it and I didn't realize this in time to get the review assigned.
      I'm also balloting DISCUSS. That is, because looking at the current ROLL charter, I have a hard time understanding how this document is in scope of the WG. This document does not fall under any of the work items on the charter; and it's not even what I'd consider a "routing" protocol.
    4. Adrian Farrel: Comment [2010-12-24]:
      Rtg Dir review from Alia Atlas says: "I have reviewed draft-ietf-roll-trickle-06. It is one of the best drafts that I have read and I do not have any substantial or even editorial comments on it. I found the protocol as described to be clear, simple and pretty elegant."
    5. Robert Sparks: Comment [2010-12-14]:
      In section 6.5 - The comment about "having the parameter describe k-1 instead of k being confusing" is confusing. I had to think for some time to convince myself that I understood what you were trying to say. I encourage you to further explain, or rewrite the comment.
      Why are you allowing different uses of trickle to give different meanings to k=0? It would seem to facilitate interoperability (and simplify implementation) if you just defined k=0 to mean turning off suppression in all cases. Individual uses of trickle can forbid setting k=0 if they don't want to allow turning off suppression.

    Telechat:

  5. Pseudowire (PW) OAM Message Mapping (Proposed Standard)
    draft-ietf-pwe3-oam-msg-map-14
    Token: Stewart Bryant
    Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd.
    IPR: Cisco's Statement about IPR Claimed in draft-ietf-pwe3-oam-msg-map-05.txt
    Discusses/comments (from ballot 3588):
    1. Adrian Farrel: Discuss [2011-01-03]:
      There are a couple of nits reported by idnits... I think the license statement should be fixed and posted (to reflect the authors' intent) before the document is approved.
      I see IPR disclosed at http://datatracker.ietf.org/ipr/863/... I don't see this declared in the proto write-up. More important, it is not present in the IETF last call announcement in datatracker.
      What is the situation wrt multi-segment PWs? I can understand that this document was developed before the WG turned to MS-PWs, but we now have RFC 5254 and RFC 5659.
      I would prefer that this document fully addressed MS-PWs...
      However, an option is to declare MS-PW out of scope, and provide a forward reference to work being done on OAM message mapping for MS-PWs in the PWE3 WG.
      Section 4.2: "If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it will be referred to as "VCCV-Ping"."
      I believe s/RFC4377/RFC5085/
      Section 5: You should add a note to explain why the CE ends of the ACs are not considered as possible defect locations. They are part of the emulated service, so a naif reader might expect to see them listed. Possibly you will want to explicitly include it in case (a).
      Additionally, your text does not match the figure: c. Defect on a PE1 PSN interface. But (c) also appears on the PE2-PSN interface in the figure.
      Furthermore, (e) and (f) appear tbe reversed in the figure compared to the text.
      Section 13: RFC 5085 and RFC 4447 should be presented as references.
      I will let Security experts comment further, but: It seems to me that facilitating end-to-end coordination of PW status and fualt reporting provides an extra tool for attackers. I would expect this to be pointed out and held up as a reason for ensuring the use of the security mechanisms.
      I think that there are security coordination issues. Perhaps these are already mentioned in the references. Consider carrying NS OAM from CE to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM Loops mode. The security relationship perceived by the CEs would presumably be between each other, but doesn't the PE need to participate?
    2. Adrian Farrel: Comment [2011-01-03]:
      Section 3: s/whereby/where/
      The Introduction uses a number of acronyms without prior expansion. On the other hand, having defined acronyms in Section 4.1, you don't gave to expand them in subsequent sections.
      Section 4.1: Several acronyms are not used in the rest of the document.
      s/label Switched Path/Label Switched Path/
      s/Operations, Administration and Maintenance/Operations, Administration, and Maintenance/
      Section 4.2: "The words "defect" and "fault" are used interchangeably to mean any condition that obstructs forwarding of user traffic between the CE endpoints of the PW service."
      I'm fine with this, but I think "obstructs" is ambiguous. Do you mean "impose a complete blockage", or do you mean to include degradation in some form? Perhaps you could add a clarification.
      Section 4.2: "If BFD is run over a PW as described in [RFC5885], it will be referred to as "VCCV-BFD".
      Add a reference to [RFC5880]
      Section 4.2: "A "transmit defect" is any defect that impacts traffic that is meant to be sent or relayed by the observing PE. A "receive defect" is any defect that impacts traffic that is meant to be received by the observing PE."
      While "meant to be" is appropriate for the reception of data, I don't think it necessarily applies to transmission. Consider that the defect may be somewhat downstream of (and not yet notfied to) the upstream PE such that the traffic that is impaced is that which *has* been sent or relayed by the observing PE.
      Additionally, the term "observing PE" has not been defined and may clarify or complicate the meaning of the text.
      I had a few problems with Section 8.1. I think my issue is with the use of the control plane as an OAM exchange mechanism (this also shows up in Appendix B). I believe the section could benefit from some polishing.
      "For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label Distribution Protocol [RFC3036] MUST use the LDP status TLV as the mechanism for AC and PW status and defect notification, as explained in [RFC4447]."
      I don't think that this "MUST" is good or consitent with:
      - the text in Section 7 that is relaxed in saying "LDP or in the ACH"
      - the work in MPLS-TP
      It sounds like 3036 (or rather 5036) is a normative reference.
      While conveying PW status in LDP per 4447 is fine, it is not OAM with the utility of rapid propagation of fault notifications. LDP, reliant as it is on TCP, is not suitable to that purpose.
      Wouldn't it be better to require the use of the ACH for OAM fault notification messages, and (if you must :-) mandate the use of LDP for status information propagation when LDP is present (but not as a replacement for real OAM).
      Additionally...: "Additionally, a PE MAY use VCCV-BFD Connectivity Verification (CV) for fault detection only (CV types 0x04 and 0x10 [RFC5885]) but SHOULD notify the remote PE using the LDP Status TLV.
      The "SHOULD" here seems to be in conflict with te previous "MUST"
      And it goes on...: "A PE that establishes a PW using means other than LDP, e.g., by static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types 0x08 and 0x20 [RFC5885]) for AC and PW status and defect notification. Note that these CV types SHOULD NOT be used when the PW is established with the LDP control plane."
      If you supply only a "MAY" you should probably describe how else the fault notification might work.
      As to the "SHOULD NOT" in the last sentence. Well, see my previous comments. And what possible harm could it do?
      Section 6: "Generally, a PE cannot detect transmit defects directly and will therefore need to be notified of AC transmit or PW transmit defects by other devices."
      I think you mean s/directly/direct/
      Section 8.1.1: "[RFC4447] specifies that the "Pseudowire forwarding" code point is used to clear all faults. It also specifies that the "Pseudowire Not Forwarding" code is used to convey any defect that cannot be represented by the other code points."
      The language seems rather week. The use of the code point does not clear the faults. It is used to report (notify) that the faults have been cleared. Likewise, defects are not conveyed by the use of a control points, but existence of the defect can be reported (or conveyed, if you like).
    3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

    Telechat:

  6. RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions (Proposed Standard)
    draft-ietf-avt-rtcp-port-for-ssm-04
    Token: Robert Sparks
    Note: The document shepherd for this document is Keith Drage (keith.drage@alcatel-lucent.com).
    Discusses/comments (from ballot 3614):
    1. Adrian Farrel: Comment [2011-01-05]:
      As idnits points out, you can strip the RFC 2119 boilerplate and reference. I'm sure the RFC Editor can handle this.
    2. David Harrington: Comment [2011-01-05]:
      1) in section 1, "the +1 rule" is mentioned without definition or reference.
    3. Sean Turner: Comment [2011-01-05]:
      Section 5 has: "This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] when SDP is used in a signaling packet using MIME types (application/sdp)."
      Technically, S/MIME messages aren't in [RFC5652] they're in [RFC5751]. RFC 5652 is CMS, which is profiled for email in RFC 5751. I've noted that when used with SDP S/MIME has been referred to as follows: RFC 4566 uses text that is similar, but omits a reference for S/MIME; RFC 4657 uses RFC 3851 (previous version of RFC 5751); RFC 4658 uses RFC 3851; RFC 3605 uses RFC 3852 (prior version of RFC 5652); RFC 3261 refers to both 2633 (S/MIME) and 2630 (CMS). Maybe the right approach is to point to both CMS and S/MIME.

    Telechat:

  7. Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (Proposed Standard)
    draft-ietf-avt-rtp-cnames-03
    Token: Robert Sparks
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3635):
    1. Stewart Bryant: Discuss [2011-01-05]:
      I think it would be helpful to the reader to briefly note that whilst the methods described in this document are good enough for most practical purposes they are not technically perfect. Whilst I can see no particular problem in the application described here, these methods may well be re-purposed as convenient general purpose UID mechanisms.
      Specifically when the method described in (5) does not use an EUI-64 there is a non-zero probability of collision, and the method in (4) that uses the MAC address is only as good as the quality procedures and ethics of the hardware manufacturer.
    2. Adrian Farrel: Comment [2011-01-05]:
      Support Stewart's Discuss since we have observed "clone" equipment with identical MAC addresses in the past. Also, I believe that some h/w exists with configurable MAC addresses.
      Abstract" s/these/those/
    3. Russ Housley: Discuss [2011-01-05]:
      The Gen-ART Review by Suresh Krishnan on 2-Jan-2011 raised an issue that needs to be resolved before publication. Section 5, Step 2, describes the use of an EUI-64 identifier and how to generate one if it does not exist. The procedure for the creation of the EUI-64 from a 48-bit MAC address is incorrect: ...
      While I recognize that no interoperability issues will result from this difference, there may be issues with testing if this is not resolved. Therfore, I suggest using the term "modified EUI-64" instead of EUI-64 or changing the reference from RFC 4291 to the IEEE document.
    4. Alexey Melnikov: Comment [2010-12-25]:
      5. Procedure to Generate a Unique Identifier: "2. Obtain an EUI-64 identifier from the system running this..."
      I think this needs an Informative reference to a document which explains what is EUI-64.
    5. Tim Polk: Comment [2011-01-06]:
      I support Sean's discuss: hard-coding SHA-1 is unnecessary and counterproductive. There is no reason that all clients need to use the same secure hash algorithm, IMHO. (For example, two clients using SHA-256 and SHA-512 are no more likely to generate a collision than two clients using SHA-256.) I suggest "compute a message digest using a secure hash function (e.g., SHA-256)" would provide the right level of detail for section 5.
      A short paragraph should also be added to the security considerations section with appropriate references. (I think Sean's discuss has the right list.)
      I would also note that the algorithm in section 5 does not *guarantee* uniqueness. I think your odds of a collision are one in 2**48 (but check with a real mathematician!). I note this since the Requirements section states "It is believed that obtaining uniqueness is an important property ..."
      Section 4.2, third bullet: "After performing the procedure, the significant 96 bits are used ..."
      Please specify "most significant" or "least significant"; the latter would be consistent with the preceding bullet.
    6. Dan Romascanu: Comment [2011-01-04]:
      1. "After obtaining a identifier by doing (a) or (b), the least significant 48 bits are converted to the standard colon-separated hexadecimal format, e.g., "00:23:32:af:9b:aa", resulting in a 17-octet printable string representation.
      It would be good to provide a reference for this 'standard ... format'. RFC 5342 uses a different notation, so arguably there is more than one format used in RFCs.
      2. Also from 5342 - here is a reference for EUI-64 which could be added (also answers the COMMENT from Alexey)
    7. Peter Saint-Andre: Discuss [2011-01-05]:
      This is a fine document with the laudable goal of improving interoperability, but in one respect I think it is both overly specific and unclear about the requirements it is working to meet.
      Section 4.1 states: "An implementation that wishes to discourage this type of third-party monitoring can generate a unique RTCP CNAME for each RTP session...."
      However, a unique identifier does not necessarily discourage third-party monitoring, e.g., incrementing from UniqueID-1 UniqueID-2 might ensure uniqueness but not privacy. I suggest that we provide a reference to RFC 4086 here and recommend that those who desire privacy need to generate identifiers that are not only unique but also random.
      This issue is connected to Section 4.2, which mandates one algorithm for long-term identifiers and a different algorithm for short-term identifiers (with seemingly different security properties, since long-term identifiers are 36 octets in length whereas short-term identifiers are only 17 octets in length). Would an implementation that generates a UUID for short-term identifiers violate the spec? If so, why? As long as the short-term identifier is unique, the implementation has met the relevant requirement. (Perhaps there is a further requirement or desire to make the identifier random, as mentioned above, but that is a separate issue.)
    8. Sean Turner: Discuss [2011-01-06]:
      #2 was revised based on some side discussions.
      #1) Section 5: On the use of SHA-1: What properties are you looking from the output? If you require no collisions then SHA-1 is probably a bad idea (see https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/). It would be much better to use SHA-256 and truncate it. And, then point to https://datatracker.ietf.org/doc/draft-eastlake-sha2b/. Yes it is a dependency but it's in AD Evaluation.
      #2) Section 5: Algorithm agility would be really nice here. Locking yourself in to one hash algorithm isn't a good idea. If the client is the only entity that is ever going to generate this hash true algorithm agility might not be needed, but you could get it by picking a length you want and then saying that one of the algorithms x, y, or z MUST be used. That way the implementer can pick on that they're doing in their cipher suite.
    9. Sean Turner: Comment [2011-01-05]:
      Section 4: Need to add "NOT RECOMMENDED" to Section 2. It's used as a key word and the 2119 errata allow it, but you need to include it as shown in the errata (http://www.rfc-editor.org/errata_search.php?rfc=2119).
      Any chance for an example per-session unique identifier?

    Telechat:

  8. Domain Name System (DNS) IANA Considerations (BCP)
    draft-ietf-dnsext-5395bis-02
    Token: Ralph Droms
    Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.
    Discusses/comments (from ballot 3657):
    1. Jari Arkko: Comment [2011-01-05]:
      This is a good document and should go forward. A few comments regarding the comments and discusses from other ADs:
      - I do not believe this document is the place to obsolete z-bit. This is an IANA considerations doc.
      - Regarding URLs and the template, I note that Specification Required is not explictly called for. Maybe it should be, and that would solve the URL problem (as the semantics of Specification Required have been defined elsewhere and reference stability is one criteria).
    2. Stewart Bryant: Comment [2011-01-05]:
      I agree with David Harrington's discuss.
    3. Adrian Farrel: Discuss [2011-01-05]:
      A small piece of IANA pedantry... Section 1.1: "IETF Standards Action", "IETF Review", "Specification Required", and "Private Use" are as defined in [RFC5226].
      5226 uses the term "Standards Action" not "IETF Standards Action". Could you fix this up throughout the document?
    4. Adrian Farrel: Comment [2011-01-05]:
      A nit: The Abstract reads... "Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes."
      Pedantically, this Abstract says nothing about *this* document. Could you make it read... "This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of..."
    5. David Harrington: Discuss [2011-01-04]:
      in section 2.1, should the document state that the ancient usage is hereby obsoleted and the z-bit MUST NOT be used for this ancient purpose in implmenetations compliant to this spec?
      in Annex 1, field E, should the document specify that it MUST be a long-lived, stable URL if a URL is used? What happens if the URL disappears? Should a document be required for escrow purposes?
    6. David Harrington: Comment [2011-01-04]:
      in section 1, s/is the change is the public review mailing list /is the change to the public review mailing list/
      in section 2.3, might it be good to recommend NOT overloading the values, ala the 16 bit, since we have 60000+ bits available?
      section 3.1.4 uses MX RR without prior definition, or reference to the definition.
      in Annex 1, field E, why does this end in a colon?
      why is field J on a totally separate page?
    7. Alexey Melnikov: Comment [2010-12-19]:
      I have a couple of comments. Taking into consideration that this is a bis document, I am making them Comment-level:
      1) 3.1.1. DNS RRTYPE Allocation Policy: "No less than three weeks and no more than six weeks after a completed template has been formally posted to dnsext@ietf.org, the selected Expert shall post a message, explicitly accepting or rejecting the application, to IANA, dnsext@ietf.org, and the email address provided by the applicant. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA."
      The last sentence: is "rejection by silence" a good idea? Has this worked well in the past?
      2) Excuse my ignorance, but what is the relationship between 2 mailing lists:
      3.1.1. DNS RRTYPE Allocation Policy: "No less than three weeks and no more than six weeks after a completed template has been formally posted to dnsext@ietf.org, the selected Expert shall post a message, explicitly accepting or rejecting the application, to IANA, dnsext@ietf.org, and the email address provided by the applicant."
      5. IANA Considerations: This document consists entirely of DNS IANA Considerations.
      "IANA shall establish a process for accepting Annex A templates, selecting an Expert from those appointed to review such template form applications, and archive and make available all approved RRTYPE allocation templates. It is the duty of the applicant to post the formal application template to the dns-rrtype-applications@ietf.org mailing list. See Section 3.1 and Annex A for more details."
      Is a request always posted to dns-rrtype-applications@ietf.org and then to dnsext@ietf.org? If the answer is yes, why have 2 mailing lists?

    Telechat:

  9. The use of AES-192 and AES-256 in Secure RTP (Proposed Standard)
    draft-ietf-avt-srtp-big-aes-05
    Token: Robert Sparks
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3659):
    1. Russ Housley: Discuss [2011-01-02]:
      The Gen-ART Review by Richard Barnes on 10-Dec-2010 raises a question that deserves a response. I have not see a response to the question.
    2. Russ Housley: Comment [2011-01-02]:
      Please consider the nit and editorial comments from the Gen-ART Review by Richard Barnes on 10-Dec-2010:
    3. Alexey Melnikov: Comment [2010-12-24]:
      3.1. Usage Requirements: "When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as"
      I think the 2nd AES_192_CM should be AES_192_CM_PRF
      "the key derivation function, and AES_128_CM MUST NOT be used as the"
      s/AES_128_CM/AES_128_CM_PRF ?
      "When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as the key derivation function. Both AES_128_CM and AES_192_CM MUST NOT be used as the key derivation function."
      Same comments as above.
    4. Tim Polk: Comment [2011-01-04]:
      Please note Hilarie Orman's secdir review.
      (1) In particular, she notes: "The block counter "b_c" is two octets, but the "default key lifetime" is 2^31. Is this perhaps the "maximum" key lifetime? Should implementors introduce an internal counter to keep track of the history of key usage (across sessions?)? Perhaps earlier documents explain this?"
      Should implementers use the rollover counter (ROC) from RFC 3711 in combination with b_c, or is there another mechanism that the authors had in mind?
      (2) You might consider moving the rationale to the front of the section as an alternative to Hilarie's suggestions on section 3.1,
    5. Sean Turner: Discuss [2011-01-05]:
      I don't think SHA-1 is part of any Suite B specifications. Because of this, it's unclear to me that you should hint that by implementing this RFC an implementation would be considered Suite B compliant.
    6. Sean Turner: Comment [2011-01-05]:
      #1) Support Russ' and Tim's discusses.
      #2) Section 3: "In this note, the AES-192 counter mode PRF and AES-256 counter mode PRF are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF respectively."
      extra words "are and"?
      #3) Section 3.1 (similar to Russ's 2nd comment): Should the rationale include a MUST?

    Telechat:

2.1.2 Returning Items

  1. MPLS Upstream Label Assignment for LDP (Proposed Standard)
    draft-ietf-mpls-ldp-upstream-09
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    IPR: Juniper's Statement of IPR related to draft-ietf-mpls-ldp-upstream-03
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-ldp-upstream-09 and draft-ietf-mpls-ldp-p2mp-11
    Discusses/comments (from ballot 3375):
    1. Jari Arkko: Discuss [2010-12-02]:
      Section 5 should explain what the semantics of the second field of the Sub-TLVs are. Presumably that has been defined in some earlier RFC that defined the syntax for Sub-TLVs. A reference would suffice.
      Reference to Section 4.2 for some behaviour needs to be changed as there is no Section 4.2.
    2. Jari Arkko: Comment [2010-12-02]:
      A few comments from Ari Keränen:...
    3. Stewart Bryant: Comment [2010-12-02]:
      (blank)
    4. Adrian Farrel: Comment [2010-12-02]:
      Gen Art review comments from Avshalom Houri...
    5. David Harrington: Comment [2010-11-30]:
      SECTION 3: s/MUST be carried only LDP initialization messages/MUST be carried only in LDP initialization messages/
    6. Russ Housley: Comment [2010-11-28]:
      The Gen-ART Review by Avshalom Houri on 13-Oct-2010 includes some editorial suggestions. Please consider them.
    7. Sean Turner: Comment [2010-11-30]:
      Section 4: Shouldn't the two "optional"s be "OPTIONAL"? They're indicating support requirements.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Cloud Data Management Interface (CDMI) Media Types (Proposed Standard)
    draft-cdmi-mediatypes-06
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3598):
    1. Adrian Farrel: Comment [2011-01-05]:
      Support Alexey's Discuss wrt the reference to 4627 and the potential positioning of this document as Informational in which case I don't think the minimal usage of 2119 language would suffer from being changed to lower case, since it seems to be referenced from another specification.
    2. Alexey Melnikov: Discuss [2010-12-21]:
      [Updated as per -06]
      DISCUSS DISCUSS (something that I want to discuss with IESG, no action from the author required):
      RFC 4627 is a Normative reference, so this is a DOWNREF. If the document is changed to Informational, the issue will go away.
    3. Alexey Melnikov: Comment [2010-12-21]:
      (blank)
    4. Sean Turner: Discuss [2011-01-05]:
      #1) Sec 3.1: "The implementations are free to store the data in any form they choose, but the application/cdmi-object SHOULD be represented in the CDMI interface as defined in section 8 of the CDMI specification."
      Seems like there's a normative reference missing to the CDMI spec.
      #2) Sec 3.2: "The implementations are free to represent the container in any form they choose, but the application/cdmi-container SHOULD be represented in the CDMI interface as defined in section 9 of the CDMI specification."
      Seems like there's a normative reference missing to the CDMI spec.
      #3) Sec 4 says: "We do not expect the CDMI to operate over other protocols, nor to use a transport protocol, such as TCP (RFC 793), directly."
      Sec 6.1 says: "CDMI does not contain any specific mechanisms, and relies on transport mechanisms such as TLS (see https [RFC2818]) for confidentiality and integrity of the messages across the network."
      Is Sec 4 wrong? 2818 doesn't mandate TCP, but it sure strong hints at it.
    5. Sean Turner: Comment [2011-01-05]:
      From Sec 3.2: ... includes standardized and optional metadata.
      There can be standardized optional metadata - no? Is this "required and optional meadata"?

    Telechat:

  2. Moving mailserver: URI scheme to historic (Proposed Standard)
    draft-melnikov-mailserver-uri-to-historic-00
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3639):
    1. Sean Turner: Comment [2011-01-05]:
      Should "Updates: 1738 (once approved)" appear on the 1st page?

    Telechat:

  3. Authentication-Results Registration For Vouch By Reference Results (Proposed Standard)
    draft-kucherawy-authres-vbr-02
    Token: Alexey Melnikov
    Note: Barry Leiba <barryleiba@computer.org> is the document shepherd.
    Discusses/comments (from ballot 3658):
    1. (none)

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Operations, Administration and Maintenance Framework for MPLS- based Transport Networks (Informational)
    draft-ietf-mpls-tp-oam-framework-10
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    IPR: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07
    Discusses/comments (from ballot 3411):
    1. Stewart Bryant: Discuss [2011-01-05]:
      I am concerned about this text: "Protection Switching: default transmission period is 3.33ms (i.e. transmission rate of 300 packets/second)."
      Firstly the the requirement in RFC5654 only specifies the total time to detect and to act as 50ms and how the system partitions this time should be a local matter.
      Secondly there are some applications of MPLS-TP that may not need this high peed detection, and it is unreasonable to burden them with the need to implement this high speed detection mechanism.
    2. Adrian Farrel: Comment [2010-12-31]:
      Three Directorate reviews have been addressed, but a few non-blocking comments remain that should be addressed to improve the document before it is published as an RFC:
      SecDir - vincent.roca@inrialpes.fr ...
      GenArt - david.black@emc.com ...
      RtgDir - thomas.morin@orange-ftgroup.com ...
    3. Russ Housley: Comment [2011-01-02]:
      The Gen-ART Review by David Black lead to some document updates. However, one comment was not addressed. Please consider updates to the security considerations section. David said:
      "[D] The security considerations section should include specific mention of injection of LKI request OAM packets as a vector for a denial-of-service attack (this is an obvious way for a man-in-the-middle to quickly cause serious havoc). That would be a good specific example to add to the end of the current security considerations paragraph that requires the network to be physically secure against man-in-the-middle attacks."
      While the security considerations section does cover the countermeasures necessary to prevent this attack, it seems like a good idea to document something that can go badly wrong when implementers do not pay attention.

    Telechat:

  2. Sieve Email Filtering: Use of Presence Information with Auto Responder functionality (Informational)
    draft-ietf-sieve-autoreply-03
    Token: Peter Saint-Andre
    Note: The Document Shepherd is Cyrus Daboo.
    Discusses/comments (from ballot 3525):
    1. Stewart Bryant: Comment [2011-01-05]:
      This is somewhat unusual language to find in a RFC to be:
      Consider whether it's truly important to tell people that you'll read their mail in an hour or so, or whether that can just be taken as how email works. There are times when this makes sense, but let's not use it to exacerbate information overload.
    2. Adrian Farrel: Comment [2011-01-05]:
      Your homily to users in Section 1 is a good message, but I think it is in the wrong document or targeted at the wrong audience. *This* document would, I think, mainly apply to application developers since it is an unusual user who writes their own Seive scripts. So the warning is better rephrased to advise application developers to be careful to not provide too many knobs and whistles, or to make sure that their implementations warn users to exercise appropriate caution.
      I would also note in this context that presence information might be a good tool to reduce the amount of autoresponses generated thus mitigating the sad effect of auto-responder functionality.
      Section 4: "Despite the "intelligence", too, errors in scripts can result in private information getting to senders inappropriately."
      Is "too," superfluous? I find it hard to parse.
    3. Robert Sparks: Comment [2011-01-05]:
      Example 2 in section 3 does what the last paragraph in section 1 says is a bad idea. Please consider reconciling these two parts of the document.

    Telechat:

  3. LoST Service List Boundary Extension (Experimental)
    draft-ietf-ecrit-lost-servicelistboundary-05
    Token: Robert Sparks
    Note: Richard Barnes (rbarnes@bbn.com) is the document shepherd.
    Discusses/comments (from ballot 3548):
    1. Tim Polk: Comment [2011-01-06]:
      This document *defines* a Service List Boundary extension, not *proposes* a Service List Boundary. Perhaps the -00 draft was a proposal, but this one is a technical specification.
      I suggest a minor edit in the Abstract to clarify the document scope.
    2. Sean Turner: Discuss [2011-01-05]:
      Section 3.2, 2nd to last paragraph: Add a normative reference to BCP 106/RFC 4086 for randomness requirements (should have been in RFC 5222).
    3. Sean Turner: Comment [2011-01-05]:
      Sec 3.3: r/is optional and/is OPTIONAL and

    Telechat:

  4. IP Flow Anonymisation Support (Experimental)
    draft-ietf-ipfix-anon-05
    Token: Dan Romascanu
    Note: Nevil Brownlee is the Document Shepherd
    Discusses/comments (from ballot 3589):
    1. Stewart Bryant: Discuss [2010-12-13]:
      In the security section you say: "When releasing anonymised data, publishers need to ensure that data that could be used in deanonymisation is not leaked through the export protocol; guidelines for addressing this risk are provided in Section 7.2."
      However it's not just protocol action that needs to be secured, the anonymising system (i.e. h/w, s/w, operational procedures) itself needs to be secure and is a system that will be the prime focus of any attack to recover the base data.
    2. Stewart Bryant: Comment [2010-12-13]:
      "Binning can be seen as a special case of precision degradation; the operation is identical, except for in precision degradation the counter ranges are uniform, and in binning they need not be. For example, a common counter binning scheme for packet counters could be to bin values 1-2 together, and 3-infinity together, thereby separating potentially completely-opened TCP connections from unopened ones.
      I am not a TCP specialist, so I do not understand the leap from the simple text "to bin values 1-2 together, and 3-infinity together" to the TCP connection example, however I suspect that grouping and the protocol state are in the wrong order. Either way, a few more words of a different example would add clarity.
    3. Adrian Farrel: Comment [2011-01-03]:
      Thanks for bringing this work forward as Experimental. While it is not a requirement, I think it is helpful to the community if Experimental documents give some indication of the scope of the experiment. Where will these protocol extensions be used? How will they be kept separate from the wider IPFIX deployment? How will the success or failure of the experiment be judged? What is the plan, assuming success? (The latter is usually: return to update this document based on experience, and move it to the standards track.) Note that some of the answers were presented in the proto writeup.
      I see questions from IANA in the data tracker that appear to have been answered by email during IETF last call. It would be good to get these answers transfered into the document or added as an RFC Editor Note. Additionally, the registry referenced is split into two ranges, but there is no advice to IANA about which range should be used.
    4. Alexey Melnikov: Comment [2010-12-26]:
      5.1. Stability: "If no information about stability is available, users of anonymised data MAY assume that the techniques used are stable across the entire dataset, but unstable across datasets."
      This doesn't look like an implementation choice, so I think MAY is wrong here.
      6.1. Anonymisation Records and the Anonymisation Options Template: "First, reliability is important: an Exporting Process SHOULD export Anonymisation Records after the Templates they describe have been exported, and SHOULD export anonymisation records reliably."
      What is the exact meaning of the last SHOULD?
      TLS and DTLS need Informational References.

    Telechat:

  5. Security Concerns With IP Tunneling (Informational)
    draft-ietf-v6ops-tunnel-security-concerns-04
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com) v6ops wg cochair is the document shepherd.
    Discusses/comments (from ballot 3615):
    1. Jari Arkko: Comment [2011-01-05]:
      Section 6.1.1 attack does not appear to be any worse than the assumptions required for this attack to be possible. If you can spoof the victim's DNS, you can hijack the victim's communications, tunnels or no tunnels.
      In this light the recommendation to prefer IPv4 over tunneled IPv6 is odd. Also, its not clear that whoever is selecting which addresses to use is aware of whether tunneling is being done or not (host vs. router, for instance).
      (This recommendation may be good for other reasons, of course.)
    2. Stewart Bryant: Comment [2011-01-05]:
      There are a lot of tunnel mechanisms are being deployed simply so that end users can work around the fact that they do not have enough IP addresses by creating a private overlay network.
      The document seems to miss the opportunity to say that by deploying IPv6 the need for many of these tunnels can be removed.
    3. Adrian Farrel: Discuss [2011-01-05]:
      I *think* that the scope of this document is intended to be "security considerations for the use of IP tunnels in IPv6 migration scenarios."
      It looks like the document goes on mainly to consider the issues that arise in such situations, although the title and abstract etc. are not clear on this limitation, and some places in the text seem to open the discussion up more general tunneling applications.
      While v6ops is a good home for a document with limited scope, it worries me that the more general discussion is restricted to that working group. The shepherd write-up declares "The document has been quite extensively socialized", without explaining where this socialization took place.
      In short, scoped so widely (i.e., not limited to the applicability of tunnels to v6 migration strategies) this document appears to be out of scope for the v6ops working group.
      There would appear to be two solutions:
      1. Add a few small changes to make clear that the scope is limited to v6 migration (or maybe to v6 use of tunnels)
      2. Find the right review forums within the IETF to ensure proper breadth of review (opsec, WGs responsible for the main tunneling protocols, ...)
      Note that I do not consider that the IETF last call on a document with a file name starting "draft-ietf-v6ops-..." guarantees broad enough review.
      I would like to see a little more clarity on the meaning of "IP tunnels". I think you are trying to discuss situations where an IP packet can contain, through some form of encapsulation, another IP packet. It would be really nice to make this crystal clear.
    4. Adrian Farrel: Comment [2011-01-05]:
      Section 2.1.1: "This reduces defense in depth and may cause security gaps."
      I can't parse this :-( Do you mean... "This reduces the depth of security available, and may cause security gaps."
      Is it right that Section 2.3 is limited only to source routing? Isn't it the case that tunneling can be used to inject any IP option into a network and cause trouble?
    5. Russ Housley: Discuss [2011-01-05]:
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question that has not been answered. I think that a response is needed.
    6. Tim Polk: Comment [2011-01-05]:
      Issue #1: I think the intended scope of this document is not consistently stated (explicitly and implicitly):
      (1) the document title is "Tunneling Security Concerns";
      (2) the abstract states "The primary intent of this document is to raise the awareness level ..."
      (3) the introduction states "This document discusses security concerns ... and includes recommendations where relevant."
      (4) the introduction also states "The primary intent is to help improve security deployments ..."
      Based on the title and the abstract, I was expecting a problem statement draft. The first bit I quoted from the intro implies that this is a problem statement draft, and the recommendations are an afterthought. The last bit says the recommendations are the whole point of the document.
      IMHO, the recommendations are the most important contribution made by this document. I would like to see edits in the abstract and intro to clearly state that. It may be too late to address the title, but "Mitigating Tunneling Security Concerns" would also clearly demonstrate that scope.
      Issue #2: The document presents a collection of network architecture and network administration recommendations, but readers might really benefit from some summary recommendations. I was hoping for a section that moved the document from a laundry list to a methodology of sorts that worked through the architectural decisions first, then moved on to mitigating the specific problems remaining after the architectural decisions are made. For example, it seems that architecting your network so that tunnels don't cross security boundaries is a key first step. If you don't follow that recommendation, everything else is harder, isn't it?
      Issue #3: The introduction closes with "The intended audience ... includes network administrators and future protocol developers." I had a hard time understanding what the lessons are for future protocol developers.
      Perhaps a paragraph or two summarizing recommendations for protocol developers would be useful here.
      Issue #3: Section 5.1 is conspicuous in its structure: it includes a "5.1.1 Problem", but omits the expected "5.1.2 Discussion" and "5.1.3 Recommendations". Is it true that there is nothing to say here?

    Telechat:

  6. Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (Informational)
    draft-ietf-v6ops-tunnel-loops-01
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd.
    Discusses/comments (from ballot 3637):
    1. Jari Arkko: Discuss [2011-01-05]:
      This is a good document and should be published. However, I have one concern about the described neighbor cache check solution. First off, the document is incorrect that hosts must continuously send RSes to keep their address configuration up to date. More importantly, the neighbor cache is just that, a cache. A better solution would be to probe for a neighbor and only drop the packet if there was no response. This is already described in the document. My suggestion would be to delete the neighbor cache check solution entirely from the document.
      I think it would also be great if this document made a stronger statement about the IMO most important use case for automatic tunnels: broadband home networks. These are very simple networks with just one exit router and it would be important to highlight the significance (or lack thereof) of the attack in this case & point to the recommended solution.
    2. Stewart Bryant: Discuss [2011-01-05]:
      "based on protocol-41 encapsulation" needs a reference
      I have tried to read section 2 a number of times and I do not understand the loop.
      I do not understand what "The attacker exploits the fact that R2 does not know that R1 does not take part of T2" means.
    3. Adrian Farrel: Discuss [2011-01-06]:
      Having had some time to go back and re-read this document I am now not comfortable.
      1. In Figure 1, why is R2 advertising reachability to an IPv6 at all? It has only one point of attachment to the v6 network. I think you are trying to say that there is a virtual link (v6 capable) running over the v4 network. Isn't that link simply part of the v6 network?
      2. Why is R2 advertising reachability to an address that is not reachable through it? You say: "...destined to a fictitious end point that appears to be reached via T2..."
    4. Russ Housley: Discuss [2011-01-05]:
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question that has not been answered. I think that a response is needed.
    5. Tim Polk: Comment [2011-01-05]:
      Please clarify that the document's scope does not address the Teredo attacks specified in the USENIX paper.
    6. Peter Saint-Andre: Comment [2011-01-05]:
      Given that the document describes an attack that can result in denial of service, a reference to RFC 4732 would be appropriate.

    Telechat:

3.1.2 Returning Items

  1. VPLS Interoperability with CE Bridges (Informational)
    draft-ietf-l2vpn-vpls-bridge-interop-06
    Token: Stewart Bryant
    Note: Shane Amante <Shane.Amante@Level3.com> is the document shepherd.
    Discusses/comments (from ballot 2633):
    1. Adrian Farrel: Comment [2010-03-09]:
      The new revision addresses a number of the points I raised in my review of 11-Apr-2009. I will clear my Discuss and record the three unaddressed points here.
      Section 2: Maybe this could use a figure. There is a lot of information conveyed and perhaps a figure of a VPLS showing the network and instance would help.
      Figure 2+: I can sort of look at figures 1 and 2 and see a more complete picture of the PE model with PWs on one side and CEs on another. I think that in figure 2 it would help to label the ACs (C-VLANs), but it would also be helpful to show CE attachment when the ACs are not VLANs. Is there some way to give this more comprehensive picture?
      Section 9: To me, this section feels very light. I am not a security expert, but the fact that you are extending an architectural model should give rise to new security issues for consideration.
    2. Sam Hartman: Discuss [2007-12-19]:
      Security directorate comments by Phillip Hallam-baker have not been addressed. These comments were not submitted as public last call comments. However they raise serious readability and interpretability questions of the document. I do know that some of Phil's comments are wrong because I've read some of the VPLS base specs. So, I tried to make an independent review of the document in order to determine if there was anything blocking. However I failed to be able to comprehend the document well enough to follow it. I gave up in the middle of section 3 with very little understanding of where the document was going and low confidence that the description of VPLS in this document matched my understanding from the base VPLS specs.
      To make this discuss actionable, I recommend that the authors work with reviewers outside their working group and improve the document to a point where someone who has not worked extensively in the L2VPN working group but who has read the VPLS documents can easily follow the document and can accurately describe what is going on.
    3. Russ Housley: Comment [2010-03-10]:
      (blank)
    4. David Ward: Discuss [2007-12-20]:
      Unfort, I find the doc very, very terse and almost unable to understand the points that are being made and the suggested recommendations. In addition I find it odd that there are cases where interop needs to be "worked out." It suggests that an interop procedure or recommendation is incomplete and thus, the doc is premature.

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP (Informational)
    draft-loreto-http-bidirectional-07
    Token: Alexey Melnikov
    Note: Martin Thomson <Martin.Thomson@andrew.com> is the document shepherd.

    Discusses/comments (from ballot 3451):
    1. Sean Turner: Comment [2011-01-05]:
      Sec 8: r/attacks.[RFC4732]./attacks [RFC4732].

    Telechat:

  2. Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (Informational)
    draft-turner-md5-seccon-update-08
    Token: Alexey Melnikov
    Note: Sean Turner (turners@ieca.com) is the document shepherd.
    Discusses/comments (from ballot 3493):
    1. Russ Housley: Comment [2011-01-05]:
      I think this documnet would be more useful to people trying to choose an algorithm if Section 2 were structured to present the conclusions at the beginning, and then provide the details in the susbsections. I suggest:
      "MD5 was published in 1992 as an Informational RFC. Since that time, MD5 has been extensively studied and new cryptographic attacks have been discovered. Message digest algorithms are designed to provide collision, pre-image, and second pre-image resistance. In addition, message digest algorithms are used with a shared secret value for message authentication in HMAC, and in this context, some people may find the guidance for key lengths and algorithm strengths in [SP800-57] and [SP800-131] useful.
      "MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5. Alternatives to HMAC-MD5 include HMAC-SHA256 [HMAC][HMAC-SHA256] and [AES-CMAC] when AES is more readily available than a hash function."

    Telechat:

  3. MD2 to Historic Status (Informational)
    draft-turner-md2-to-historic-10
    Token: Robert Sparks
    Note: Sean Turner (turners@ieca.com) is the document Shepherd.
    Discusses/comments (from ballot 3575):
    1. Adrian Farrel: Comment [2011-01-04]:
      Comment transferred from my previous process Discuss.
      I fully support knocking MD2 on the head. However, I am a little inexperienced with the process of making an I-D Historic.
      What happens to an standards track documents with references (especially normative references) to 1319 as listed in Section 3? Should they at least also be marked as "updated by" this draft?
      Similarly, 1319 updates 1115. What happens to 1115 and its text on MD2?
    2. Alexey Melnikov: Comment [2010-12-19]:
      Updates: 1319 (once approved)
      - why not Obsolete: 1319 ? This document is moving RFC 1319 to Historic.
      3. Documents that Reference RFC 1319
      MD2 has been specified in the following RFCs:
      *Use* of MD2 has been specified ...

    Telechat:

  4. MD4 to Historic Status (Informational)
    draft-turner-md4-to-historic-10
    Token: Robert Sparks
    Note: Sean Turner (turners@ieca.com) is the document Shepherd.
    Discusses/comments (from ballot 3611):
    1. Adrian Farrel: Comment [2011-01-05]:
      As with the MD2 document, I think it is worth listing the standards track documents shown in Section 3 as Updated in the document header.
      It looks to me that you might also want to update some of the informational documents listed here.
      The prime benefit is that those documents will be marked in the RFC repository as having been updated by this document.
      Abstract, etc.: Once published, this document should be more assertive. Thus:
      OLD: This document recommends RFC 1320 be moved to Historic status.
      NEW: This document moves RFC 1320 to Historic status.
      4. Impact on Moving MD4 to Historic: s/on/of/
      Section 4: MD4 was used in the Inter-Domain Routing Protocol (IDRP); each IDRP message carries a 16-octet hash that is computed by applying the MD-4 algorithm (RFC 1320) to the context of the message itself. Over time IDRP was replaced by BGP-4."
      Need to add a refernce to 4271, and an indication that BGP-4 requires at least MD-5. You could reference 2385, but that might be de trop.
      Section 4: "The three Microsoft RFCs, [RFC2433], [RFC2759], and [RFC4757], are:
      Do we need to describe these as "Microsoft RFCs"? How about: "The three RFCs describing Microsoft protocols"?
    2. Alexey Melnikov: Comment [2010-12-19]:
      The document header has: "Updates: 1320 (once approved)" Why not "Obsoletes: 1320" ?

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational)
    draft-zorn-radius-keywrap-17
    Token: Dan Romascanu
    Discusses/comments (from ballot 2377):
    1. (none)

    Telechat:

  2. A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization (Informational)
    draft-irtf-mobopts-mpa-framework-08
    Token: Jari Arkko
    Note: Rajeev Koodli (rkoodli@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3602):
    1. Ralph Droms: Comment [2011-01-06]:
      I strongly suggest that the following comments are addressed before publication:
      In section 7.3.1, a DHCP relay agent does not have the capability to operate independently and perform a DHCP message exchange with a DHCP server in anticipation of an eventual DHCP message exchange initiated by a client. The mecahnism described in this section would require the definition of a new DHCP proxy function.
      In the case of IPv6, it's probably required to forward the RA to the mobile node regardless of the address assignment model, to pre-configure the mobile node with all the requisite information about prefixes, etc.
      In section 7.3.3, there is a conflict with the DHCPv6 specification, which requires that a DHCPv6 client send any messages to the DHCPv6 servers/relays multicast address, rather than unicast to a server.
      There may also be a problem with all of these methods using DHCP: how does the CTN DHCP server know what address to assign to the client?
      Other comments:
      Perhaps a nit, but I was somewhat mislead by the title, "A Framework of Media-Independent Pre-Authentication (MPA) for Inter-domain Handover Optimization" to believe that I was going to read about a protocol that focused on authentication and secure communication. In my opinion, this document describes a complete framework for media-independent inter-domain handover optimization that goes beyond authentication and security.
      In Appendix A, wouldn't DAD be performed by the NAR rather than the PAR?
      From the Intro: "In this document we discuss a framework to support terminal mobility that provides seamless handovers with low latency and low loss."
      Are there other components to terminal mobility aside from MPA?
      Section 1.2: "A trade-off between one-way-delay and packet loss is desired based on the type of application."
      Unclear to me - a trade-off should be available through tuning or one-way-delay should be improved relative to packet loss?
      Section 3: Define "inter-subnet handover"?
      Section 6.1: "MPA provides three basic procedures to provide this functionality. The first procedure is referred to as "pre-authentication", the second procedure is referred to as "pre-configuration", the combination of the third and fourth procedures are referred to as "secure proactive handover"."
      "three basic procedures" and "third and fourth procedures" is confusing; where did that fourth procedure come from?
      Section 6.1: "Especially, the third procedure described above (i.e., binding update procedure)"
      Change "third procedure described above" to "step (iii) in the previous paragraph" to avoid confusion with the use of "procedures in the earlier paragraph in section 6.1.
      Section 6.2: "The authentication protocol MUST be able to derive a key between the mobile node and the authentication agent and SHOULD be able to provide mutual authentication."
      Is "derive a key between ..." a term of art or can the requirement be described more accurately as "establish a shared key between..."?
      "The authentication protocol SHOULD be able to interact with a AAA protocol such as RADIUS and Diameter to carry authentication credentials to an appropriate authentication server in the AAA infrastructure."
      Does the authentication protocol interact directly with the AAA protocol, or does the interaction happen through the AA?

    Telechat:

3.3.2 Returning Items

  1. The Internet Routing Overlay Network (IRON) (Experimental)
    draft-templin-iron-16
    Token: Jari Arkko
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot 3638):
    1. Jari Arkko: Comment [2010-12-16]:
      (blank)
    2. Stewart Bryant: Comment [2010-12-15]:
      I am surprise that the document contains no reference to LISP which is operating broadly in this space.
      SRA is not a defined abbreviation.
      This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay.
      "After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages."
      "If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping."
      "quickly" is a non-specific metric
      [I-D.templin-intarea-seal] looks like it should be normative
      [I-D.templin-intarea-vet] looks like it should be normative
      Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.
    3. Ralph Droms: Comment [2010-12-16]:
      I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it?
      The remainder of my COMMENTs are editorial.
      In Section 6.1, I think I understand what this text is trying to explain, but I don't think it's correct:
      "It is therefore essential that the Client send the initial packets through its Server to avoid loss of SCMP messages that cannot traverse a NAT in the reverse direction."
      Does this mean to explain that the Client sends packets through its Server to establish NAT state so SCMP messages from the Server to the Client can traverse the NAT?
      In Section 6.2, this text uses "into the Internet" in a confusing way, assuming I'm understanding the meaning of the text correctly:
      "The Server then forwards the revised packet into the Internet via a default or more-specific route, where it will be directed to the closest Relay within the destination VPC overlay network."
      Everywhere else in this section "into the Internet" is used to describe the forwarding of a decapsulated datagram, after the outer header with locator addresses have been removed, into the (non-IRON) Internet. In the text quoted aboce, "into the Internet" seems to mean forwarding of an encapsulated datagram, which is described elsewhere in this section as simply "forwards" or "sends". I suggest rewriting, for consistency, as
      "The Server then forwards to the closest Relay within the destination VPC overlay network."
      In Figure 6, why would the anycast datagram from Server(A) be delivered to Relay(B) rather than Relay(A) (which presumably would be in the routing fabric for ISP A)? Does it matter?
      Once Server(B) receives the datagram to be forwarded to Client(B), is it possible for Server(B) to send a redirect to Client(A) so Client(A) can send traffic directly to Client(B)?
      Stylistic nit in section 6.4.1 (and elsewhere) - why start using the verb "releases" instead of the previously used "forwards" or "sends"? Seems like lots of unnecessary verbiage right after Figure 6; why not something like "..., host A sends packets to host B through its EUN. Client(A), as the defautl router for the EUN, receives the packets, encapsulates them in the IRON encapsulation and forwards them to Server(A). ..." (etc.) All the explanation of routing, etc., seems redundant at this point.
      Sorry, can't help myself; in section 6.6:
      "The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates."
      ... as opposed to the unethical business practices and unreasonably high rates from those evil, greedy ISPs.
      Seriously, has the renumbering problem simply been moved from the ISPs to the VPCs?
    4. Adrian Farrel: Comment [2010-12-16]:
      Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions.
      I feel that it would be helpful if the document contained a pointer to draft-irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.

    Telechat:

1253 EST break

1258 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Audio/Video Transport Payloads (payload)
    Token: Robert

    Telechat:

  2. Metric Blocks for use with RTCP's Extended Report Framework (xrblock)
    Token: Robert

    Telechat:

  3. Audio/Video Transport Core Maintenence (avtcore)
    Token: Robert

    Telechat:

  4. Audio/Video Transport Extensions (avtext)
    Token: Robert

    Telechat:

4.1.2 Proposed for Approval

  1. ControLling mUltiple streams for TElepresence (clue)
    Token: Gonzalo

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IPFIX interoperability meeting in Prague (Dan Romascanu)

    Telechat:

  2. WG and BoF Scheduling for IETF 80 (Russ)

    Telechat:

  3. Note (Amy)

    Telechat:

7. Agenda Working Group News

1338 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-01-06 07:27:56 PST)

draft-ietf-pkix-ocspagility

  1. Jari Arkko: Discuss [2011-01-04]:
        
    > A responder MAY maximize the potential for ensuring interoperability
    > by selecting a supported signature algorithm using the following
    > order of precedence, as long as the selected algorithm meets all
    > security requirements of the OCSP responder, where the first method
    > has the highest precedence:
    >
    > 1.  Select an algorithm specified as a preferred signing algorithm in
    >     the client request
    >
    > 2.  Select the signing algorithm used to sign a CRL issued by the
    >     certificate issuer providing status information for the
    >     certificate specified by CertID
    >
    > 3.  Select the signing algorithm used to sign the OCSPRequest
    >
    > 4.  Select a signature algorithm that has been advertised as being
    >     the default signature algorithm for the signing service using an
    >     out of band mechanism
    >
    > 5.  Select a mandatory or recommended signing algorithm specified for
    >     the version of the OCSP protocol in use
    >
    > A responder SHOULD always apply the lowest numbered selection
    > mechanism that is known, supported, and that meets the responder's
    > criteria for cryptographic algorithm strength.
    
    I am confused by the last sentence and how it uses the words "selection
    mechanism". Does this sentence talk about algorithms or the above selection
    methods? But the selection methods do not have an algorithmic strength, nor are
    they negotiated. Suggested replacement text:
    
    A responder SHOULD always apply the lowest numbered selecetion mechanism that
    results in the selection of a known and supported algorithm that meets the
    responder's criteria for cryptographic algorithm strength. 
        
  2. Jari Arkko: Comment [2011-01-04]:
    
        
  3. Adrian Farrel: Discuss [2011-01-05]:
        I find a small discrepency at the end of Section 4
    
       The server SHOULD use one of the preferred signature algorithms for
       signing OCSP responses to the requesting client.
    
    This means (I think) that the server MAY use an algarithm not listed by the
    client as preferred. You need to cover:
    - under what circumstances
    - what
    expectations of success it will have
    
    But, in fact, I think the whole of Section 5 is dedicated to the question of how
    to select a suitable algorithm, and that means that this sentence in Section 4
    needs to be replaced with:
    
       Section 5 of this document describes how a server selects an
       algorithm for signing OCSP responses to the requesting client. 
        
  4. Adrian Farrel: Comment [2011-01-05]:
    The RFC Editor will ask you to remove the citation from the Abstract. 
    
    ---
    
    http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt shows 
    that OCSP is not a "well-known" acronym. SO could you please expand it 
    in the document title, the Abstract, and on first use in Section 2.
    
    ---
    
    A number of other acronyms are used without expansion.
    CA
    CRL
    DSA
    
    ---
    
    Section 5.1
    
    Did you think of splitting option 5 into:
      5. select a mandatory algorithm
      6. select a recommended algorithm
    since there is a very marked difference in the likelihood of success.
    
  5. Alexey Melnikov: Comment [2011-01-04]:
    In Section 4:
    
       The client MUST support each of the specified preferred signature
       algorithms and the client MUST specify the algorithms in the order of
       preference.
    
    I think this is not actually saying what the order is. I suggest adding
    something like
    "from the most preferred to the least preferred"
    
    8.3. Denial of Service Attack
    
       Algorithm agility mechanisms defined in this document introduces a
       slightly increased attack surface for Denial of Service attacks where
       the client request is altered to require algorithms that are not
       supported by the server, alternatively does not match pre-generated
       responses.
    
    The last part (after the final comma) is not readable.
    
    [NEWASN] - is this a Downref? If it is (and it wasn't explicitly called out
    during the IETF LC), is [NEWASN] in the Downref registry?
  6. Peter Saint-Andre: Comment [2011-01-05]:
    1. Section 8.1 uses the phrases "considered unacceptably insecure" and "not
    considered acceptably secure". Are these equivalent?
    
    2. In Section 8.3, please consider citing RFC 4732 on the concept of denial of
    service attacks.
  7. Sean Turner: Comment [2011-01-04]:
    I am going to recuse myself from this draft because I was involved in proposing
    the ASN.1 structure.  I don't consider that an insignificant contribution.  I am
    however happy with this draft.

draft-ietf-httpstate-cookie

  1. Jari Arkko: Comment [2011-01-03]:
    I agree with the Discusses from Alexey, Robert, Tim, and for the most part with
    Sean. I do not agree with the Discuss from Adrian. Obviously the document can
    make those actions.
  2. Adrian Farrel: Comment [2010-12-13]:
    Section 1
    
    Please don't be so timid.
    
    OLD
       This
       document attempts to specify the syntax and semantics of these
       headers as they are actually used on the Internet.
    NEW
       This
       document specifies the syntax and semantics of these
       headers as they are actually used on the Internet.
    END
    
    ---
    
    Section 10.2
    
    You have:
    
       [Netscape]
                  Netscape Communications Corp., "Persistent Client State --
                  HTTP Cookies", 1999, <http://web.archive.org/web/
                  20020803110822/http://wp.netscape.com/newsref/std/
                  cookie_spec.html>.
    
    1. Are you sure this is the best version of the spec? The document is
       headed: "Preliminary Specification - Use with caution"
    
    2. RFC Erratum 1491 reads:
    
         Section 12 says:
    
         [Netscape] "Persistent Client State -- HTTP Cookies", available at
                    <http://www.netscape.com/newsref/std/cookie_spec.html>,
                    undated.
    
         It should say:
    
         [Netscape] "Persistent Client State -- HTTP Cookies", available at
                    <http://www.netscape.com/newsref/std/cookie_spec.html>,
                    undated.
    
                    Copy avalaible at <http://curl.haxx.se/rfc/cookie_spec.html>
    
       Can you confirm that you do not need to add a "copy available"
       statement to this document?
    
       (See http://www.rfc-editor.org/errata_search.php?eid=1491)
    
    ---
    
    Erratum 2644 seems to have been submitted after the date of your I-D.
    I assume that this Erratum will be rejected as soon as your I-D
    becomes an RFC.
                                                        
       (See http://www.rfc-editor.org/errata_search.php?eid=2644)
    
    ---
    
    Section 2.1
    In particular, the algorithms defined in this
       specification are intended to
    be easy to understand and are not
       intended to be performant.
    
    Do you really mean "performant" which my dictionary gives only as a 
    noun meaning " a perforemer".
    
    I found
    http://weblogs.asp.net/jgalloway/archive/2007/05/10/performant-isn-t-a-word.aspx
    
  3. Alexey Melnikov: Discuss [2010-12-20]:
        [Updated as per -20]
    
    This is a well written document. I am contemplating voting Yes on this document
    once my issues (see below) are discussed/resolved, not because Cookies are
    pretty, but because this is the best attempt to describe them properly.
    
    7) In Section 5.4:
    
       NOTE: Despite its name, the cookie-string is actually a sequence of
       octets, not a sequence of characters.  To convert the cookie-string
       (or components thereof) into a sequence of characters (e.g., for
       presentation to the user), the user agent might wish use the UTF-8
       character encoding [RFC3629] to decode the octet sequence.
    
    Clients can't assume that an arbitrary sequence of octets generated by the
    server would be a valid UTF-8.
    This needs to be clarified.
    
    9) From Lisa Dusseault's Apps Area Review:
    
    Section 3. "Origin servers can send a Set-Cookie response header with
    any response.".  Do we happen to know if it's more common for user
    agents to handle, or ignore Set-Cookie response headers on error
    responses?  I'd be surprised if user-agents do handle them including
    on 500-level, 400-level and particularly on a 100 Continue response,
    but I haven't tested it.  Is it part of your tests?  So while this
    statement is factual, it might not help servers much.  If my
    assumption about some clients ignoring the header on some classes of
    responses is correct, I would add that information to the document in
    a non-normative sentence.
     
        
  4. Alexey Melnikov: Comment [2010-12-20]:
    5.1.1.  Dates
    
       year            = 1*4DIGIT ( non-digit *OCTET )
    
    Do people really use 1 digit and 3 digit years?
    I very much doubt that a single digit year is allowed, so may I suggest:
    
       year            = 2*4DIGIT ( non-digit *OCTET )
    
  5. Tim Polk: Discuss [2011-01-06]:
        This discuss was motivated in part by Richard Barnes' Gen-ART review.   Richard
    noted that:
    
    "Many of these integrity issues are caused by user agents accepting cookies from
    outside the context where they would send them, in particular with the Secure
    and Path attributes.  It seems like this document, in specifying the
    desired/proper behavior of user agents, should require behavior that would
    mitigate these attacks.  In direct parallel to the handling of the Domain
    attribute:
     1. Set-Cookies with the Secure flag should only be accepted over
    secure channels
     2. Set-Cookies with the Path attribute set should only be
    accepted if the path value matches the request-uri of the request
    (That is,
    update Steps 7 and 8 of S5.3 to match Steps 6 and 9/10)
    
    The author responded:
    "I agree that these would be desirable changes to the cookie protocol.
    However, the http-state working group is not chartered to change the
    cookie protocol.  In particular, the charter reads as follows:
    
         The working group must not introduce any new syntax or new semantics
         not already in common use."
    
    I understand that this document cannot impose new rules or syntax.  However, as
    written this document
    appears to *prohibit* clients from extending the algorithm
    to protect themselves:  User agents are required
    to implement algorithms
    "equivalent to" the algorithms specified in Section 5  to process dates (section
    5.1.1),
    paths (5.1.4), parse a set cookie string (Section 5.2), and the
    processing the cookie (Section 5.3, which was
    at the heart of Richard's issues),
    processing the cookie header (section 5.4), etc.  This does not leave an
    implementer with any wiggle room, forcing them to accept insecure processing
    rules.
    
    This document should not prohibit clients from doing additional processing to
    enhance their own security,
    especially since the processing rules proposed by
    Richard apparently would not affect interoperability with
    a well-behaved server.
    
    I believe that a better model is the PKIX path validation processing algorithm,
    where "functionally equivalent"
    implementations are required but are explicitly
    permitted to extend the model to enhance security.  For example,
    some
    implementers have chosen to require that a certificate and CRL be signed by the
    same cryptographic key
    to guard against name collisions.  This is not required
    by PKIX but implementations that include this feature
    are still compliant.
    
    Is there a good reason why extensions to the user agent's processing cannot be
    extended as Richard suggested? 
        
  6. Tim Polk: Comment [2010-12-16]:
    I found the following Note at the end of 4.1.1 confusing:
    
       NOTE: Some user agents represent dates using 32-bit UNIX time_t
       values.  Some of these user agents might contain bugs that cause them
       to process dates after the year 2038 incorrectly.
    
    After considering this for a while, I concluded that the point is that user
    agents
    might convert the dates into UNIX time_t values for storage and
    processing, and
    implementation bugs mean that dates after 2038 are not
    interpreted correctly.  If
    that is correct, then maybe the following would be an
    appropriate substitution:
    
       NOTE: Some user agents store and process dates in cookies as 32-bit UNIX
    time_t values.  Implementation bugs in the libraries supporting time_t
    processing
       on some systems may cause such user agents to process dates after
    the year
       2038 incorrectly.
    
    
  7. Robert Sparks: Discuss [2010-12-14]:
        In 4.1.1 (Syntax) - Why is the specification part of this proposed standard
    allowing implementations to 
    violate the grammar defined by this standard? The
    SHOULD NOT in the first paragraph of this section must
    be a MUST NOT. If the
    intent is to make sure clients are liberal in what they accept because existing
    servers may generate non-conformant grammar, just say that (and if possible,
    point to what they might
    need to expect). If the intent is to allow servers that
    are compliant to generate messages not covered
    by this grammar, then the grammar
    is incorrect. If that's the case, the grammar should be extended to 
    allow the
    alternate behavior and the document's prose can say that servers SHOULD NOT use
    those parts 
    of the grammar.
    
        
  8. Robert Sparks: Comment [2010-12-14]:
    Please consider moving the SHOULD in the first of the two NOTE:s at the end of
    4.1.1 out of the NOTE.
    
    Consider noting in the discussion of "public suffixes" that the problems this
    mechanism attempts
    to avoid are still present in deeper heirarchies (A server at
    math.example.edu will be able to
    set cookies for example.edu, potentially
    affecting the behavior of infosec.example.edu)
  9. Sean Turner: Discuss [2010-12-16]:
        [These are my preliminary discusses.  I might find more later.]
    
    This is a well written document, but I've got a couple of things I'd like to
    discuss:
    
    #1) I'd like to see a new security consideration section that addresses
    persistent cookies.  I think we need to mention how expiry date can be abused.
    Is there some kind of recommendation we can give on their lifetimes?  Are
    cookies good for 2, 5, 20 years okay?
    
    #2) I'd like to see a new privacy|security consideration that says what's being
    touted as "private browsing" doesn't protect cookies it only stops the history
    from being updated.
    
    #3) Section 7.1:  I understand it's hard to have one policy for third-party
    cookies.  But, couldn't we say that assuming sites aren't behaving badly or
    somehow otherwise sharing tracking data that users that wish to not be tracked
    by third-parties ensure that third-party cookies be blocked?
    
    #4) Section 7.2:  It's not a protocol thing, but should we really make the
    following two SHOULDs:
    
    User agents should provide users with a mechanism for managing the
       cookies stored in the cookie store.
    
    User agents should provide users with a mechanism for disabling
       cookies.
    
    #5) Section 8.3/8.5: Should point out that the format for signature/encryption
    is server specific.
    
    #6) Section 8.3, last paragraph:
    
    a) The last paragraph, I believe, discusses "sidejacking" and "cookie monster"
    attacks (or is that the 1st paragraph in 8.5?).  Is it worth explicitly
    mentioning the name of these attacks?
    
    b) To that end, can we add something like (I'm not wed to the words) the
    following to the end of the paragraph in 8.3:
    
    For example, a webmail server that is initially accessed via HTTPS but later
    exchanges mail (and cookies) over HTTP will expose whatever cookie (and mail) is
    exchanged between the client and server.  Sidejacking is when a MITM intercepts
    the HTTP exchanges.  If a server incorrectly sets the Secure attribute and sends
    a cookie that otherwise should have been sent over a secure channel, a MITM can
    access the cookie (sometimes called a cookie monster attack).
    
    #7) Sec 8:  Where would we say something about how when multiple users use the
    same machine, they're not protected from one another?
    
    #8) Sec 8: Shouldn't we have a section on cross-site scripting attacks (i.e.,
    scripts that make browser send cookies to malicious servers that should not
    receive them) and how http-only helps?  I.e., servers should set httpOnly to
    stop these?
    
    #9) Sec 4.2/8 ?: Where are cookie poising attack discussed (i.e., client returns
    a different cookie than the one set by the server)? 
        
  10. Sean Turner: Comment [2010-12-16]:
    #1) Section 4: It's odd that following is in Section 4, which is titled Server
    Requirements:
    
       User agents,
       however, MUST implement the requirements in Section 5 to ensure
       interoperability with servers making use of the full semantics.
    
    Shouldn't it be in Section 5?
    
    #2) In Section 5.2, add "(see Section 7.1)" to the end of:
    
    For example, the user agent might wish to block responses to "third-party"
    requests from setting cookies.
    
    #3) In Section 5.4, add "(see Section 7.1)" to the end of:
    
    For example, the user agent might wish to block sending cookies during "third-
    party" requests.

draft-ietf-pim-group-rp-mapping

  1. Adrian Farrel: Comment [2010-12-31]:
    Routing Area Directorate review by Dimitri Papadimitriou raises a few very minor
    editorial points that should be looked at together with any other comments and
    issues raised during IESG review.
    
    > Section 1: 
    > 
    > - "Each PIM-SM router may learn Group-to-RP mappings through
    >    various mechanisms." which mechanisms ? ref's would be helpful
    > 
    > - "It is critical that each router select the same 'RP' for a specific
    >    multicast group address." why ? a short sentence would be helpful
    >    - note this requirement applies to al routers in the same "domain"
    > 
    > Section 4:
    > 
    > - "A Group-to-RP mapping learned for PIM-BIDIR mode is preferred to
    >    an entry learned for PIM-SM mode."
    >    is this reason dictated by arbitrary criteria or protocol operation 
    >    criteria (dictated by RFC 5059) or other ?
    > 
    > Section 5: 
    > 
    > - Add ref's to BSR and Auto-RP in sentence
    >   "In this case, to support some specific applications, they might like to
    >    learn Group-to-RP mappings dynamically using either BSR or Auto-RP
    >    mechanism."
    > 
    > - "This is not an issue for IPv6 Multicast address ranges." what "this" 
    >    refers to ?
    > 
    > Section 6:
    > 
    > - What's the input to this algorithm ? there is a need to describe the set
    >   of information onto which this procedure applies (the output is implicit).
    > 
    > - The description seems to mandate a sequential execution (from 1 to
    >    10) but this is not stated ahead in the Section 6.
    > 
    > Section 9:
    > 
    > - " The algorithm in this document MUST be used. " on all routers in 
    >   the domain? Please clarify. 
    > 
    > - "improve stability under misconfiguration" stability of what ? 
    > 
    > Section 11:
    > 
    > - does the term "block" refers to disable or filter ? or left unspecified ?
  2. Tim Polk: Discuss [2011-01-05]:
        This is a pretty straightforward discuss, and should be easy to clear.  As noted
    in Vincent Roca's security
    directorate review, the document would benefit from
    some expansion of the security considerations.  In particular,
    some pointers to
    mechanisms for learning group-to-rp mappings that satisfy the constraint are
    considered secure
    would be helpful.  Please use Vincent's review as an input to
    your revisions. 
        
  3. Dan Romascanu: Discuss [2011-01-04]:
        The issue of the relation between this document and RFC 5060 was raised by
    Adrian with the MIB Doctors. At the end of the discussion which prompted to
    various methods of altering the behavior of the routers that already support the
    MIB module the resolution communicated by Adrian was: 'we have decided that we
    do NOT want to update the semantics of the existing objects'.
    
    I am still to be convinced that this is the case. 
    
    7.  Interpretation of MIB Objects
    
       The algorithm defined in this document does not use the concept of
       precedence and therefore the values configured in the
       'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence' objects of
       the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060]
       are not applicable to the new algorithm.  The objects still retain
       their meaning for 'legacy' implementations, but since the algorithm
       defined in this document is to be used in preference to that found in
       PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields
       will decline as implementations are upgraded to support the new
       algorithm.
    
    First, in RFC 5060 the  'pimGroupMappingPrecedence' and 'pimStaticRPPrecedence'
    objects are in two different tables - pimGroupMappingTable and pimStaticRPTable.
    Each of the table has a different 'precedence' object and a different behavior.
    
    Does pimStaticRPTable has any function with the new RP mapping algorithm? In RFC
    5060 it is used to define static entries that may precede and override those
    defined by the algorithm in 5060. Does this apply also to the algorithm defined
    here?
    
    What does exactly mean 'the usage of these fields will decline'? All the MIB
    module defined in RFC 5060 is supported ('we do not want to update the
    semantics') - so what happens with the pimGroupMappingTable? Section 8 describes
    how objects in this table will continue to be used to indicate Group-to-RP
    mapping.   Whay I am missing is what happenss if a manager creates a new entry
    as per RFC 5060? Should the router just ignore it? We cannot assume all managers
    are 'well-bahaved' and we need to prevent I think mis-configuration.
    
    If the writeable part of the of this table is not disabled, this would be a
    serious security problem, as it would interfere with the works of the new
    algorithm.
    
    A proper solution should include an update of RFC 5060, including changes in
    MODULE-COMPLIANCE and possibly a new read-only table that would help the
    operators read the entries created as result of the application of the new
    mechanism. I understand that the authors and WG do not plan to do this in the
    near future, but they need to define a clear and acceptable behavior of the
    agents runing RFC 5060. Dully obsoleting RFC 5060 (and the usage of the MIB
    module defined there) would be another solution at this point, but this is not
    what the WG wants, as I understand. 
        
  4. Dan Romascanu: Comment [2011-01-04]:
    1. Section 5: 
    
       A network management station can determine the RP for a specific
       group in a specific router by running this algorithm on the
       Group-to-RP mapping table fetched using SNMP MIB objects.
    
    MIB objects are meant to work not only with SNMP. Please change 'SNMP MIB
    objects' to 'SMI MIB objects' or just 'MIB objects'.
    
    2. Need to expand MIB and SNMP at first occurence. 
  5. Peter Saint-Andre: Discuss [2011-01-05]:
        This is a fine document. However, the algorithm does not specify rules for
    determining which hash value or IP address is "highest", which might inhibit
    interoperability. Please specify such rules (e.g., convert to "network byte
    order" octet string representation and then apply i;octet collation from RFC
    4790), or refer to specifications that define such rules. 
        

draft-ietf-roll-trickle

  1. Stewart Bryant: Discuss [2010-12-15]:
        "All that matters is that
       some nodes communicate with one another at some nonzero rate."
    
    This is not right. If every node received, nothing would get communicated. In
    addition I tend to think of communication as requiring some degree transmission.
    
    I think that you mean transmits at some nonzero rate.
    
    =======
    
    Considering that later text says that Trickle breaks if there is a parameter
    mismatch, I am concerned that this text is not strict enough:
    
       It is RECOMMENDED that a protocol which uses Trickle includes
       mechanisms to inform nodes of configuration parameters at runtime.
       However, it is not always possible to do so.  
    
    I am also concerned with the get out clause that allows the degradation of a
    MUST to a RECOMMENDATION. Surely for the cost of a few bytes the parameters can
    at least be announced so that other nodes can get some hint that the mismatch is
    occurring. 
        
  2. Ralph Droms: Comment [2010-12-14]:
    Nit: 3rd para of section 3, s/their/its/
    
    Question: is the typical value of k in the range 1-5 independent of
    the density of the network nodes, where I'm thinking of "density" as
    the number of nodes that hear a given message?
    
  3. Lars Eggert: Discuss [2010-12-16]:
        I'm sorry for deferring this document to the next telechat. I want the TSV
    directorate to review it and I didn't realize this in time to get the review
    assigned.
    
    I'm also balloting DISCUSS. That is, because looking at the current ROLL
    charter, I have a hard time understanding how this document is in scope of the
    WG. This document does not fall under any of the work items on the charter; and
    it's not even what I'd consider a "routing" protocol. 
        
  4. Adrian Farrel: Comment [2010-12-24]:
    Rtg Dir review from Alia Atlas says:
    
    I have reviewed draft-ietf-roll-trickle-06.   It is one of the best drafts that
    I have read and I do not have any substantial or even editorial comments on it.
    I found the protocol as described to be clear, simple and pretty elegant.
  5. Robert Sparks: Comment [2010-12-14]:
    In section 6.5 - The comment about "having the parameter describe k-1 instead of
    k being confusing" is confusing. I had to think for some time to convince myself
    that I understood what you were trying to say. I encourage you to further
    explain, or rewrite the comment.
    
    Why are you allowing different uses of trickle to give different meanings to
    k=0? It would seem to facilitate interoperability (and simplify implementation)
    if you just defined k=0 to mean turning off suppression in all cases. Individual
    uses of trickle can forbid setting k=0 if they don't want to allow turning off
    suppression.

draft-ietf-pwe3-oam-msg-map

  1. Adrian Farrel: Discuss [2011-01-03]:
        There are a couple of nits reported by idnits (an out of date reference,
    an old license statement). I think the license statement should be
    fixed and posted (to reflect the authors' intent) before the document is
    approved.
    
    ---
    
    I see IPR disclosed at http://datatracker.ietf.org/ipr/863/
    I don't see this declared in the proto write-up. More important, it is
    not present in the IETF last call announcement in datatracker.
    
    ---
    What is the situation wrt multi-segment PWs? I can understand that this
    document
    was developed before the WG turned to MS-PWs, but we now have
    RFC 5254 and RFC
    5659.
    
    I would prefer that this document fully addressed MS-PWs. That would not
    be hard because each PW segment at an S-PE regards the adjacent segments
    as ACs, so it could probably be addressed in just one or two paragraphs
    in a new section.
    
    However, an option is to declare MS-PW out of scope, and provide a
    forward
    reference to work being done on OAM message mapping for MS-PWs
    in the PWE3 WG.
    
    ---
    
    Section 4.2
    
       If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it
       will be referred to as "VCCV-Ping".
    
    I believe s/RFC4377/RFC5085/
    
    ---
    
    Section 5
    You should add a note to explain why the CE ends of the ACs are not
    considered
    as possible defect locations. They are part of the emulated
    service, so a naif
    reader might expect to see them listed. Possibly you
    will want to explicitly
    include it in case (a).
    
    Additionally, your text does not match the figure:
       c. Defect on a PE1 PSN interface.
    But (c) also appears on the PE2-PSN interface in the figure.
    
    Furthermore, (e) and (f) appear tbe reversed in the figure compared to
    the text.
    
    ---
    
    Section 13
    
    RFC 5085 and RFC 4447 should be presented as references.
    
    I will let Security experts comment further, but:
    
     It seems to me that facilitating end-to-end coordination of PW status
     and fualt reporting provides an extra tool for attackers. I would
     expect this to be pointed out and held up as a reason for ensuring the
     use of the security mechanisms.
    
     I think that there are security coordination issues. Perhaps these are 
     already mentioned in the references. Consider carrying NS OAM from CE 
     to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM
     Loops mode. The security relationship perceived by the CEs would 
     presumably be between each other, but doesn't the PE need to 
     participate? 
        
  2. Adrian Farrel: Comment [2011-01-03]:
    Section 3                  
    s/whereby/where/
    
    ---
    
    The Introduction uses a number of acronyms without prior expansion.
    On the other hand, having defined acronyms in Section 4.1, you don't
    gave to expand them in subsequent sections.
    
    ---
    
    Section 4.1
    Several acronyms are not used in the rest of the document.
    BDI
    CPCS
    IWF
    
    s/label Switched Path/Label Switched Path/
    s/Operations, Administration and Maintenance/
      Operations, Administration, and Maintenance/
    
    ---
    
    Section 4.2
    
       The words "defect" and "fault" are used interchangeably to mean any
       condition that obstructs forwarding of user traffic between the CE
       endpoints of the PW service.
    
    I'm fine with this, but I think "obstructs" is ambiguous. Do you mean
    "impose a complete blockage", or do you mean to include degradation in
    some form? Perhaps you could add a clarification.
    
    ---
    
    Section 4.2
    
       If BFD is run over a PW as
       described in [RFC5885], it will be referred to as "VCCV-BFD".
    
    Add a reference to [RFC5880]
    
    ---
    
    Section 4.2
    
       A "transmit defect" is any defect that impacts traffic that is meant
       to be sent or relayed by the observing PE.  A "receive defect" is any
       defect that impacts traffic that is meant to be received by the
       observing PE.
    
    While "meant to be" is appropriate for the reception of data, I don't
    think it necessarily applies to transmission. Consider that the defect
    may be somewhat downstream of (and not yet notfied to) the upstream PE
    such that the traffic that is impaced is that which *has* been sent or
    relayed by the observing PE.
    
    Additionally, the term "observing PE" has not been defined and may
    clarify or complicate the meaning of the text.
    
    ---
    
    I had a few problems with Section 8.1. I think my issue is with the
    use of the control plane as an OAM exchange mechanism (this also shows
    up in Appendix B). I believe the section could benefit from some
    polishing.
    
       For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label
       Distribution Protocol [RFC3036] MUST use the LDP status TLV as the
       mechanism for AC and PW status and defect notification, as explained
       in [RFC4447].
    
    I don't think that this "MUST" is good or consitent with:
    - the text in Section 7 that is relaxed in saying "LDP or in the ACH"
    - the work in MPLS-TP
    
    It sounds like 3036 (or rather 5036) is a normative reference.
    
    While conveying PW status in LDP per 4447 is fine, it is not OAM with 
    the utility of rapid propagation of fault notifications. LDP, reliant
    as it is on TCP, is not suitable to that purpose.
    
    Wouldn't it be better to require the use of the ACH for OAM fault
    notification messages, and (if you must :-) mandate the use of LDP
    for status information propagation when LDP is present (but not as a
    replacement for real OAM).
    
    Additionally...
    
       Additionally, a PE MAY use VCCV-BFD Connectivity
       Verification (CV) for
    fault detection only (CV types 0x04 and 0x10
       [RFC5885]) but SHOULD notify the
    remote PE using the LDP Status TLV.
    The "SHOULD" here seems to be in conflict with te previous "MUST"
    
    And it goes on...
    
       A PE that establishes a PW using means other than LDP, e.g., by
       static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types
       0x08 and 0x20 [RFC5885]) for AC and PW status and defect
       notification.  Note that these CV types SHOULD NOT be used when the
       PW is established with the LDP control plane.
    
    If you supply only a "MAY" you should probably describe how else the
    fault notification might work.
    
    As to the "SHOULD NOT" in the last sentence. Well, see my previous
    comments. And what possible harm could it do?
    
    ---   
    
    Section 6
    
       Generally, a PE cannot detect transmit defects directly and will
       therefore need to be notified of AC transmit or PW transmit defects
       by other devices.
    
    I think you mean s/directly/direct/
    
    ---
    
    Section 8.1.1
                                                                              
       [RFC4447] specifies that the "Pseudowire forwarding" code point is
       used to clear all faults.  It also specifies that the "Pseudowire Not
       Forwarding" code is used to convey any defect that cannot be
       represented by the other code points.
    
    The language seems rather week.
    The use of the code point does not clear the faults. It is used to 
    report (notify) that the faults have been cleared.
    Likewise, defects are not conveyed by the use of a control points, but
    existence of the defect can be reported (or conveyed, if you like).
  3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

draft-ietf-avt-rtcp-port-for-ssm

  1. Adrian Farrel: Comment [2011-01-05]:
    As idnits points out, you can strip the RFC 2119 boilerplate and 
    reference. I'm sure the RFC Editor can handle this.
  2. David Harrington: Comment [2011-01-05]:
    1) in section 1, "the +1 rule" is mentioned without definition or reference.
  3. Sean Turner: Comment [2011-01-05]:
    Section 5 has:
    
       This
       can, for example, be achieved on an end-to-end basis using S/MIME
       [RFC5652] when SDP is used in a signaling packet using MIME types
       (application/sdp).
    
    Technically, S/MIME messages aren't in [RFC5652] they're in [RFC5751].  RFC 5652
    is CMS,  which is profiled for email in RFC 5751.  I've noted that when used
    with SDP S/MIME has been referred to as follows: RFC 4566 uses text that is
    similar, but omits a reference for S/MIME; RFC 4657 uses RFC 3851 (previous
    version of RFC 5751); RFC 4658 uses RFC 3851; RFC 3605 uses RFC 3852 (prior
    version of RFC 5652); RFC 3261 refers to both 2633 (S/MIME) and 2630 (CMS).
    Maybe the right approach is to point to both CMS and S/MIME.

draft-ietf-avt-rtp-cnames

  1. Stewart Bryant: Discuss [2011-01-05]:
        I think it would be helpful to the reader to briefly note that whilst the
    methods described in this document are good enough for most practical purposes
    they are not technically perfect. Whilst I can see no particular problem in the
    application described here, these methods may well be re-purposed as convenient
    general purpose UID mechanisms.
    
    Specifically when the method described in (5) does not use an EUI-64 there is a
    non-zero probability of collision, and the method in (4) that uses the MAC
    address is only as good as the quality procedures and ethics of the hardware
    manufacturer. 
        
  2. Adrian Farrel: Comment [2011-01-05]:
    Support Stewart's Discuss since we have observed "clone" equipment with
    identical MAC addresses in the past. Also, I believe that some h/w exists with
    configurable MAC addresses.
    
    ---
    
    Abstract
    s/these/those/
    
  3. Russ Housley: Discuss [2011-01-05]:
        
      The Gen-ART Review by Suresh Krishnan on 2-Jan-2011 raised an issue
      that needs to be resolved before publication. Section 5, Step 2,
      describes the use of an EUI-64 identifier and how to generate one if
      it does not exist. The procedure for the creation of the EUI-64 from a
      48-bit MAC address is incorrect:
    
      RFC 4291 describes how to create a *modified* EUI-64 identifier (not a
      EUI-64 identifier) from a MAC address. A MAC address of
      xx:78:90:12:34:56 will be transformed to a modified EUI-64 of
      yy7890FFFE123456, where yy is the value of xx with the u/l bit (bit 6)
      flipped. The IEEE reference for creation of an EUI-64 from a 48-bit
      MAC address (http://standards.ieee.org/develop/regauth/tut/eui64.pdf)
      would result in an EUI-64 of xx7890FFFF123456 for the same MAC address.
    
      While I recognize that no interoperability issues will result from
      this difference, there may be issues with testing if this is not
      resolved. Therfore, I suggest using the term "modified EUI-64" instead
      of EUI-64 or changing the reference from RFC 4291 to the IEEE
      document.
     
        
  4. Alexey Melnikov: Comment [2010-12-25]:
    5.  Procedure to Generate a Unique Identifier
    
       2.  Obtain an EUI-64 identifier from the system running this
    
    I think this needs an Informative reference to a document which explains what is
    EUI-64.
    
           algorithm.  If an EUI-64 does not exist, one can be created from
           a 48-bit MAC address as specified in [RFC4291].  If an EUI-64
           cannot be obtained or created, a suitably unique identifier,
           local to the node, should be used (e.g., system serial number).
  5. Tim Polk: Comment [2011-01-06]:
    I support Sean's discuss: hard-coding SHA-1 is unnecessary and
    counterproductive.  There is no reason that all 
    clients need to use the same
    secure hash algorithm, IMHO.  (For example, two clients using SHA-256 and
    SHA-512
    are no more likely to generate a collision than two clients using
    SHA-256.)  I suggest "compute a message digest
    using a secure hash function
    (e.g., SHA-256)" would provide the right level of detail for section 5.
    
    A short paragraph should also be added to the security considerations section
    with appropriate references.  (I think
    Sean's discuss has the right list.)
    
    I would also note that the algorithm in section 5 does not *guarantee*
    uniqueness.  I think your odds of a collision
    are one in 2**48 (but check with a
    real mathematician!).  I note this since the Requirements section states "It is
    believed that obtaining uniqueness is an important property ..."
    
    Section 4.2, third bullet:
    
    "After performing the procedure, the significant 96 bits are used ..."
    
    Please specify "most significant" or "least significant"; the latter would be
    consistent with the preceding bullet.
  6. Dan Romascanu: Comment [2011-01-04]:
    1. 
    >    After obtaining a identifier by doing (a) or (b),
          the least significant 48 bits are converted to the standard colon-
          separated hexadecimal format, e.g., "00:23:32:af:9b:aa", resulting
          in a 17-octet printable string representation.
    
    It would be good to provide a reference for this 'standard ... format'. RFC 5342
    uses a different notation, so arguably there is more than one format used in
    RFCs.
    
    2. Also from 5342 - here is a reference for EUI-64 which could be added (also
    answers the COMMENT from Alexey)
    
    [EUI-64]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
                 Registration Authority", <http://standards.ieee.org/
                 regauth/oui/tutorials/EUI64.html>, March 1997.
  7. Peter Saint-Andre: Discuss [2011-01-05]:
        This is a fine document with the laudable goal of improving interoperability,
    but in one respect I think it is both overly specific and unclear about the
    requirements it is working to meet.
    
    Section 4.1 states:
    
       An implementation that wishes to
       discourage this type of third-party monitoring can generate a unique
       RTCP CNAME for each RTP session....
    
    However, a unique identifier does not necessarily discourage third-party
    monitoring, e.g., incrementing from UniqueID-1 UniqueID-2 might ensure
    uniqueness but not privacy. I suggest that we provide a reference to RFC 4086
    here and recommend that those who desire privacy need to generate identifiers
    that are not only unique but also random.
    
    This issue is connected to Section 4.2, which mandates one algorithm for long-
    term identifiers and a different algorithm for short-term identifiers (with
    seemingly different security properties, since long-term identifiers are 36
    octets in length whereas short-term identifiers are only 17 octets in length).
    Would an implementation that generates a UUID for short-term identifiers violate
    the spec? If so, why? As long as the short-term identifier is unique, the
    implementation has met the relevant requirement. (Perhaps there is a further
    requirement or desire to make the identifier random, as mentioned above, but
    that is a separate issue.) 
        
  8. Sean Turner: Discuss [2011-01-06]:
        #2 was revised based on some side discussions.
    
    #1) Section 5: On the use of SHA-1:  What properties are you looking from the
    output?  If you require no collisions then SHA-1 is probably a bad idea (see
    https://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/).  It would be
    much better to use SHA-256 and truncate it.  And, then point to
    https://datatracker.ietf.org/doc/draft-eastlake-sha2b/.  Yes it is a dependency
    but it's in AD Evaluation.
    
    #2) Section 5: Algorithm agility would be really nice here.  Locking yourself in
    to one hash algorithm isn't a good idea.  If the client is the only entity that
    is ever going to generate this hash true algorithm agility might not be needed,
    but you could get it by picking a length you want and then saying that one of
    the algorithms x, y, or z MUST be used.  That way the implementer can pick on
    that they're doing in their cipher suite. 
        
  9. Sean Turner: Comment [2011-01-05]:
    Section 4: Need to add "NOT RECOMMENDED" to Section 2.  It's used as a key word
    and the 2119 errata allow it, but you need to include it as shown in the errata
    (http://www.rfc-editor.org/errata_search.php?rfc=2119).
    
    Any chance for an example per-session unique identifier?

draft-ietf-dnsext-5395bis

  1. Jari Arkko: Comment [2011-01-05]:
    This is a good document and should go forward.
    
    A few comments regarding the comments and discusses from other ADs:
    
    - I do not believe this document is the place to obsolete z-bit. This is
      an IANA considerations doc.
    
    - Regarding URLs and the template, I note that Specification Required
      is not explictly called for. Maybe it should be, and that would solve
      the URL problem (as the semantics of Specification Required have
      been defined elsewhere and reference stability is one criteria).
  2. Stewart Bryant: Comment [2011-01-05]:
    I agree with David Harrington's discuss.
  3. Adrian Farrel: Discuss [2011-01-05]:
        A small piece of IANA pedantry...
    
    Section 1.1.
    
       "IETF Standards Action", "IETF Review", "Specification Required", and
       "Private Use" are as defined in [RFC5226].
    
    5226 uses the term "Standards Action" not "IETF Standards Action". Could
    you fix this up throughout the document? 
        
  4. Adrian Farrel: Comment [2011-01-05]:
    A nit:
    
    The Abstract reads...
    
       Internet Assigned Number Authority (IANA) parameter assignment
       considerations are specified for the allocation of Domain Name System
       (DNS) resource record types, CLASSes, operation codes, error codes,
       DNS protocol message header bits, and AFSDB resource record subtypes.
    
    Pedantically, this Abstract says nothing about *this* document.
    Could you make it read...
    
       This document specifies Internet Assigned Number Authority (IANA)
       parameter assignment considerations for the allocation of...
    
  5. David Harrington: Discuss [2011-01-04]:
        in section 2.1, should the document state that the ancient usage is hereby
    obsoleted and the z-bit MUST NOT be used for this ancient purpose in
    implmenetations compliant to this spec?
    
    in Annex 1, field E, should the document specify that it MUST be a long-lived,
    stable URL if a URL is used?
    What happens if the URL disappears?
    Should a
    document be required for escrow purposes?
    
        
  6. David Harrington: Comment [2011-01-04]:
    in section 1, s/is the change is the public review mailing list /is the change
    to the public review mailing list/
    
    in section 2.3, might it be good to recommend NOT overloading the values, ala
    the 16 bit, since we have 60000+ bits available?
    
    section 3.1.4 uses MX RR without prior definition, or reference to the
    definition.
    
    in Annex 1, field E, why does this end in a colon?
    
    why is field J on a totally separate page?
  7. Alexey Melnikov: Comment [2010-12-19]:
    I have a couple of comments. Taking into consideration that this is a bis
    document, I am making them Comment-level:
    
    1)
    3.1.1. DNS RRTYPE Allocation Policy
    
       No less than three weeks and no more than six weeks after a completed
       template has been formally posted to dnsext@ietf.org, the selected
       Expert shall post a message, explicitly accepting or rejecting the
       application, to IANA, dnsext@ietf.org, and the email address provided
       by the applicant. If the Expert does not post such a message, the
       application shall be considered rejected but may be re-submitted to
       IANA.
    
    The last sentence: is "rejection by silence" a good idea? Has this worked well
    in the past?
    
    2) Excuse my ignorance, but what is the relationship between 2 mailing lists:
    
    3.1.1. DNS RRTYPE Allocation Policy
    
       No less than three weeks and no more than six weeks after a completed
       template has been formally posted to dnsext@ietf.org, the selected
       Expert shall post a message, explicitly accepting or rejecting the
       application, to IANA, dnsext@ietf.org, and the email address provided
       by the applicant.
    
    5. IANA Considerations
    
       This document consists entirely of DNS IANA Considerations.
    
       IANA shall establish a process for accepting Annex A templates,
       selecting an Expert from those appointed to review such template form
       applications, and archive and make available all approved RRTYPE
       allocation templates. It is the duty of the applicant to post the
       formal application template to the dns-rrtype-applications@ietf.org
       mailing list. See Section 3.1 and Annex A for more details.
    
    Is a request always posted to dns-rrtype-applications@ietf.org and then to
    dnsext@ietf.org?
    If the answer is yes, why have 2 mailing lists?

draft-ietf-avt-srtp-big-aes

  1. Russ Housley: Discuss [2011-01-02]:
        
      The Gen-ART Review by Richard Barnes on 10-Dec-2010 raises a question
      that deserves a response.  I have not see a response to the question.
      >
      > The Suite B specifications require the use of SHA-256 and SHA-384 as
      > hash functions for SECRET and TOP SECRET, respectively.  Given that
      > Suite B compatibility is listed as an objective of this document, it
      > seems like there should be a cryptosuite that would use Suite B hash
      > algorithms as well as encryption algorithms. 
        
  2. Russ Housley: Comment [2011-01-02]:
      Please consider the nit and editorial comments from the Gen-ART Review
      by Richard Barnes on 10-Dec-2010:
      >
      > [Section3] In the first sentence, should "AES_CM PRF" be changed
      > to "AES_CM_PRF"?
      >
      > [Section3.1] Do you want to say explicitly that stronger KDFs MAY
      > be used?  That you could use the AES_256_CM KDF with AES_192_CM as
      > the bulk encryption algorithm, or use either 192 or 256 with 128?
  3. Alexey Melnikov: Comment [2010-12-24]:
    3.1.  Usage Requirements
    
       When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as
    
    I think the 2nd AES_192_CM should be AES_192_CM_PRF
    
       the key derivation function, and AES_128_CM MUST NOT be used as the
    
    s/AES_128_CM/AES_128_CM_PRF ?
    
       key derivation function.
    
       When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as
       the key derivation function.  Both AES_128_CM and AES_192_CM MUST NOT
       be used as the key derivation function.
    
    Same comments as above.
    
  4. Tim Polk: Comment [2011-01-04]:
    Please note Hilarie Orman's secdir review.
    
    (1) In particular, she notes:
    
    The block counter "b_c" is two octets, but the "default key lifetime"
    is 2^31.  Is this perhaps the "maximum" key lifetime?  Should
    implementors introduce an internal counter to keep track of the
    history of key usage (across sessions?)?  Perhaps earlier documents
    explain this?
    
    Should implementers use the rollover counter (ROC) from RFC 3711
    in combination with b_c, or is there another mechanism that the
    authors had in mind?
    
    (2)  You might consider moving the rationale to the front of the section
    as an alternative to Hilarie's suggestions on section 3.1, 
  5. Sean Turner: Discuss [2011-01-05]:
        I don't think SHA-1 is part of any Suite B specifications.  Because of this,
    it's unclear to me that you should hint that by implementing this RFC an
    implementation would be considered Suite B compliant. 
        
  6. Sean Turner: Comment [2011-01-05]:
    #1) Support Russ' and Tim's discusses.
    
    #2) Section 3: 
    
       In
       this note, the AES-192 counter mode PRF and AES-256 counter mode PRF
       are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF
       respectively.
    
    extra words "are and"?
    
    #3) Section 3.1 (similar to Russ's 2nd comment): Should the rationale include a
    MUST?  For example:
    
       The cryptographic strength of the key derivation function MUST
       meet or exceed the cryptographic strength of the encryption method.

draft-ietf-mpls-ldp-upstream

  1. Jari Arkko: Discuss [2010-12-02]:
        Section 5 should explain what the semantics of the second field of the Sub-TLVs
    are. Presumably that has been defined in some earlier RFC that defined the
    syntax for Sub-TLVs. A reference would suffice.
    
    Reference to Section 4.2 for some behaviour needs to be changed as there
    is no Section 4.2. 
        
  2. Jari Arkko: Comment [2010-12-02]:
    A few comments from Ari Keränen:
    
    The format of the packet format figures is not consistent: in the 
    section 5's sub-TLVs "type" is given with syntax "Type  = XX" whereas in 
    rest of the figures it's "Name (code)".
    
    The second field of sub-TLVs (length?) is not defined at all in the 
    figures but just the value is given. Also the length seems to include 
    the type and length of the TLV -- is that intentional? Especially since 
    in the other TLVs do not seem to include type and length.
    
    Also the sentence "The TLV value in the sub-TLV acts as the tunnel 
    identifier" is strange. Do you mean "the value of the sub-TLV"?
    
        1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of
        the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object
        [RFC4875].
    
    The second sentence above is a bit confusing. Perhaps removing the "as 
    carried in" part from the sentence and changing "value of the TLV" into 
    "value of the sub-TLV" would help, if you mean that the whole object is 
    in the value of the sub-TLV.
    
    It's also somewhat confusing that with RSVP-TE P2MP LSP TLV there are 
    Type and Length in the figure and with LDP P2MP LSP TLV there aren't.
    
    The format of the 3rd and 4th sub-TLV seems underspecified. For example, 
    how do you encode a "<Source Address, Multicast Group Address> tuple" in 
    a sub-TLV?
    
    6. LDP Point-to-Multipoint LSPs on a LAN
    
        Processing
        of the Label Request and Label Mapping messages for LDP upstream-
        assigned labels is as described in section 4.2.
    
    Section 4.2. does not exist.
    
        2. The following hash is performed: H = (Sum Opaque value) modulo N,
        where N is the number of candidate upstream LSRs. Opaque value is
        defined in [MLDP] and comprises the P2MP LSP identifier.
    
    What does the "Sum" in the hash equation mean? I would assume it's sum 
    over all opaque values if there is more than one, but it's not really 
    clear from the context. Also, how do you convert the opaque value(s) 
    into number(s)?
  3. Stewart Bryant: Comment [2010-12-02]:
    
        
  4. Adrian Farrel: Comment [2010-12-02]:
    Gen Art review comments from Avshalom Houri
    
    Summary: The document is ready for a Standard Track RFC.
    
    Major issues: None
    Minor issues: None
    
    Nits/editorial comments:
    
    One or more occurrences in the document
    a LDP -> an LDP
    a LSR -> an LSR
    a MPLS -> an MPLS
    
    Line 540
      [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the
    ->    [MLDP] describes how to setup P2MP LSPs using LDP. On a LAN the
    
    Line 572
      Ru on receiving this message sends back a Label Mapping message to Rd
    ->    On receiving this message, Ru sends back a Label Mapping message to Rd
    
  5. David Harrington: Comment [2010-11-30]:
    SECTION 3: s/MUST be carried only LDP initialization messages/MUST be carried
    only in LDP initialization messages/
  6. Russ Housley: Comment [2010-11-28]:
      The Gen-ART Review by Avshalom Houri on 13-Oct-2010 includes some
      editorial suggestions.  Please consider them.
  7. Sean Turner: Comment [2010-11-30]:
    Section 4: Shouldn't the two "optional"s be "OPTIONAL"?  They're indicating
    support requirements.

draft-cdmi-mediatypes

  1. Adrian Farrel: Comment [2011-01-05]:
    Support Alexey's Discuss wrt the reference to 4627 and the potential
    positioning of this document as Informational in which case I don't
    think the minimal usage of 2119 language would suffer from being
    changed to lower case, since it seems to be referenced from another
    specification.
  2. Alexey Melnikov: Discuss [2010-12-21]:
        [Updated as per -06]
    
    DISCUSS DISCUSS (something that I want to discuss with IESG, no action from the
    author required):
    
    RFC 4627 is a Normative reference, so this is a DOWNREF. If the document is
    changed to Informational, the issue will go away. 
        
  3. Alexey Melnikov: Comment [2010-12-21]:
    
        
  4. Sean Turner: Discuss [2011-01-05]:
        updated to remove #3
    
    #1) Sec 3.1: The implementations are free to store the data in
       any form they choose, but the application/cdmi-object SHOULD be
       represented in the CDMI interface as defined in section 8 of the CDMI
       specification.
    
    Seems like there's a normative reference missing to the CDMI spec.
    
    #2) Sec 3.2: The implementations are free to represent the
       container in any form they choose, but the application/cdmi-container
       SHOULD be represented in the CDMI interface as defined in section 9
       of the CDMI specification.
    
    Seems like there's a normative reference missing to the CDMI spec. 
        
  5. Sean Turner: Comment [2011-01-05]:
    From Sec 3.2: ... includes standardized and optional metadata.
    
    There can be standardized optional metadata - no?  Is this "required and
    optional meadata"?

draft-melnikov-mailserver-uri-to-historic

  1. Sean Turner: Comment [2011-01-05]:
    Should "Updates: 1738 (once approved)" appear on the 1st page?

draft-kucherawy-authres-vbr

  1. (none)

draft-ietf-mpls-tp-oam-framework

  1. Stewart Bryant: Discuss [2011-01-05]:
        I am concerned about this text:
    
    Protection Switching: default transmission period is 3.33ms (i.e. transmission
    rate of 300 packets/second).
    
    Firstly the the requirement in RFC5654 only specifies the total time to detect
    and to act as 50ms and how the system partitions this time should be a local
    matter.
    
    Secondly there are some applications of MPLS-TP that may not need this high peed
    detection, and it is unreasonable to burden them with the need to implement this
    high speed detection mechanism. 
        
  2. Adrian Farrel: Comment [2010-12-31]:
    Three Directorate reviews have been addressed, but a few non-blocking comments
    remain that should be addressed to improve the document before it is published
    as an RFC:
    
    SecDir - vincent.roca@inrialpes.fr
    
    > However there's a (naive) question which you didn't answer: is it
    > realistic to assume the physical network can be secured? Are there
    > known weaknesses in the MPLS infrastructure? Nothing is said in
    > the I-D.
    >
    > Another point (from -10). It is said:
    >
    >         However
    >         it should be observed that the combination of the need for
    >         timeliness of OAM transaction exchange and all permutations of
    >         unique MEP to MEP, MEP to MIP, and intermediate system
    >         originated transactions mitigates against the practical
    >         establishment and maintenance of a large number of security
    >         associations per MEG either in advance or as required.
    >
    > The reasons mentioned here to justify nothing is done is critical.
    > Only two reasons are listed: timeliness and combinatorial motivations.
    > In your answer you also mention the high transmission frequency of
    > heartbeats. This is not mentioned. Something else?
    
    GenArt - david.black@emc.com
    
    > The authors have addressed most of the items noted in the Gen-ART review
    > of
    the -09 version, but there is one item that could still use some attention.  
    >
    From the original review:
    >
    >       [D] The security considerations section
    should include specific mention
    >       of injection of LKI request OAM packets
    as a vector for a denial-of-service
    >       attack (this is an obvious way for a
    man-in-the-middle to quickly cause
    >       serious havoc).  That would be a good
    specific example to add to the end
    >       of the current security
    considerations paragraph that requires the network
    >       to be physically
    secure against man-in-the-middle attacks.
    >
    > This has not been done.  While the
    security considerations section does
    > cover the countermeasures necessary to
    prevent this attack, I prefer security
    > considerations sections that include
    examples of things that can go badly
    > wrong when implementers don't pay
    attention when the examples are simple.
    > That preference is a matter of
    style/taste that I'll leave to the responsible AD's
    > judgment
    
    RtgDir - thomas.morin@orange-ftgroup.com
    
    > I replied to Dave Allan that my current 
    > feeling, after going through today's revision of the OAM framework 
    > document, is that the comments I made are only partially addressed.
    
  3. Russ Housley: Comment [2011-01-02]:
      The Gen-ART Review by David Black lead to some document updates.
      However, one comment was not addressed.  Please consider updates
      to the security considerations section.  David said:
      >
      > [D] The security considerations section should include specific
      > mention of injection of LKI request OAM packets as a vector for a
      > denial-of-service attack (this is an obvious way for a man-in-the-
      > middle to quickly cause serious havoc).  That would be a good
      > specific example to add to the end of the current security
      > considerations paragraph that requires the network to be
      > physically secure against man-in-the-middle attacks.
      >
      While the security considerations section does cover the
      countermeasures necessary to prevent this attack, it seems like
      a good idea to document something that can go badly wrong when
      implementers do not pay attention.
    

draft-ietf-sieve-autoreply

  1. Stewart Bryant: Comment [2011-01-05]:
    This is somewhat unusual language to find in a RFC to be:
    
    Consider whether it's truly important to tell people that
       you'll read their mail in an hour or so, or whether that can just be
       taken as how email works.  There are times when this makes sense, but
       let's not use it to exacerbate information overload.
    
  2. Adrian Farrel: Comment [2011-01-05]:
    Your homily to users in Section 1 is a good message, but I think it is
    in the wrong document or targeted at the wrong audience. *This* document
    would, I think, mainly apply to application developers since it is an
    unusual user who writes their own Seive scripts. So the warning is 
    better rephrased to advise application developers to be careful to not
    provide too many knobs and whistles, or to make sure that their
    implementations warn users to exercise appropriate caution.
    
    I would also note in this context that presence information might be a
    good tool to reduce the amount of autoresponses generated thus 
    mitigating the sad effect of auto-responder functionality.
    
    ---
    
    Section 4
    
       Despite the "intelligence", too, errors in scripts can result in
       private information getting to senders inappropriately.
    
    Is "too," superfluous? I find it hard to parse.
    
  3. Robert Sparks: Comment [2011-01-05]:
    Example 2 in section 3 does what the last paragraph in section 1 says is a bad
    idea. Please consider reconciling these two parts of the document.

draft-ietf-ecrit-lost-servicelistboundary

  1. Tim Polk: Comment [2011-01-06]:
    My apologies before climbing onto the editorial soapbox, but...
    
    This document *defines* a Service List Boundary extension, not *proposes* a
    Service List Boundary.  Perhaps the
    -00 draft was a proposal, but this one is a
    technical specification.
    
    I suggest a minor edit in the Abstract to clarify the document scope.
  2. Sean Turner: Discuss [2011-01-05]:
        Section 3.2, 2nd to last paragraph: Add a normative reference to BCP 106/RFC
    4086 for randomness requirements (should have been in RFC 5222).
    
    [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,  "Randomness
    Requirements for Security", BCP 106, RFC 4086, June 2005. 
        
  3. Sean Turner: Comment [2011-01-05]:
    Sec 3.3: r/is optional and/is OPTIONAL and

draft-ietf-ipfix-anon

  1. Stewart Bryant: Discuss [2010-12-13]:
        In the security section you say
    
    "When releasing anonymised data, publishers need to ensure that data that could
    be used in deanonymisation is not leaked through the  export protocol;
    guidelines for addressing this risk are provided in Section 7.2."
    
    However it's not just protocol action that needs to be secured, the anonymising
    system (i.e. h/w, s/w, operational procedures) itself needs to be secure and is
    a system that will be the prime focus of any attack to recover the base data. 
        
  2. Stewart Bryant: Comment [2010-12-13]:
     "Binning can be seen as a special case of precision degradation; the operation
    is identical, except for in precision degradation the counter ranges are
    uniform, and in binning they need not be.  For  example, a common counter
    binning scheme for packet counters could be to bin values 1-2 together, and
    3-infinity together, thereby separating potentially completely-opened TCP
    connections from unopened ones.
    
    I am not a TCP specialist, so I do not understand the leap from the simple text
    "to bin values 1-2 together, and 3-infinity together" to the TCP connection
    example, however I suspect that grouping and the protocol state are in the wrong
    order.
    Either way, a few more words of a different example would add clarity.
  3. Adrian Farrel: Comment [2011-01-03]:
    Thanks for bringing this work forward as Experimental. While it is not a
    requirement, I think it is helpful to the community if Experimental documents
    give some indication of the scope of the experiment. Where will these protocol
    extensions be used? How will they be kept separate from the wider IPFIX
    deployment? How will the success or failure of the experiment be judged? What is
    the plan, assuming success? (The latter is usually: return to update this
    document based on experience, and move it to the standards track.) Note that
    some of the answers were presented in the proto writeup.
    
    I see questions from IANA in the data tracker that appear to have been answered
    by email during IETF last call. It would be good to get these answers transfered
    into the document or added as an RFC Editor Note. Additionally, the registry
    referenced is split into two ranges, but there is no advice to IANA about which
    range should be used.
  4. Alexey Melnikov: Comment [2010-12-26]:
    5.1.  Stability
    
       If no information about stability is available, users of anonymised
       data MAY assume that the techniques used are stable across the entire
       dataset, but unstable across datasets.
    
    This doesn't look like an implementation choice, so I think MAY is wrong here.
    
    6.1.  Anonymisation Records and the Anonymisation Options Template
    
       First, reliability is important: an
       Exporting Process SHOULD export Anonymisation Records after the
       Templates they describe have been exported, and SHOULD export
       anonymisation records reliably.
    
    What is the exact meaning of the last SHOULD?
    
    TLS and DTLS need Informational References.
    

draft-ietf-v6ops-tunnel-security-concerns

  1. Jari Arkko: Comment [2011-01-05]:
    Section 6.1.1 attack does not appear to be any worse than the assumptions
    required for this attack to be possible. If you can spoof the victim's
    DNS, you can hijack the victim's communications, tunnels or no tunnels.
    
    In this light the recommendation to prefer IPv4 over tunneled IPv6
    is odd. Also, its not clear that whoever is selecting which addresses
    to use is aware of whether tunneling is being done or not (host vs.
    router, for instance).
    
    (This recommendation may be good for other reasons, of course.)
  2. Stewart Bryant: Comment [2011-01-05]:
    There are a lot of tunnel mechanisms are being deployed simply so that end users
    can work around the fact that they do not have enough IP addresses by creating a
    private overlay network.
    
    The document seems to miss the opportunity to say that by deploying IPv6 the
    need for many of these tunnels can be removed.
  3. Adrian Farrel: Discuss [2011-01-05]:
        I think this is a worthwhile and useful document
    
    I *think* that the scope of this document is intended to be "security
    considerations for the use of IP tunnels in IPv6 migration scenarios."
    
    It looks like the document goes on mainly to consider the issues that
    arise in such situations, although the title and abstract etc. are 
    not clear on this limitation, and some places in the text seem to 
    open the discussion up more general tunneling applications.
    
    While v6ops is a good home for a document with limited scope, it
    worries me that
    the more general discussion is restricted to that                
    working group.
    The shepherd write-up declares "The document has been
    quite extensively
    socialized", without explaining where this
    socialization took place.
    
    In short, scoped so widely (i.e., not limited to the applicability of
    tunnels to v6 migration strategies) this document appears to be out of
    scope for the v6ops working group.
    
    There would appear to be two solutions:
    1. Add a few small changes to make clear
    that the scope is limited to                          
       v6 migration (or maybe
    to v6 use of tunnels)
    2. Find the right review forums within the IETF to ensure
    proper
       breadth of review (opsec, WGs responsible for the main tunneling
    protocols, ...)
    
    Note that I do not consider that the IETF last call on a document with
    a file name starting "draft-ietf-v6ops-..." guarantees broad enough
    review.
    
    ---
    
    I would like to see a little more clarity on the meaning of "IP 
    tunnels". I think you are trying to discuss situations where an IP
    packet can contain, through some form of encapsulation, another IP
    packet. It would be really nice to make this crystal clear.
     
        
  4. Adrian Farrel: Comment [2011-01-05]:
    Section 2.1.1
    
       This reduces defense in depth
       and may cause security gaps.
    
    I can't parse this :-( Do you mean...
    
    This reduces the depth of security available, and may cause security 
    gaps.
    
    ---
    
    Is it right that Section 2.3 is limited only to source routing? Isn't
    it the case that tunneling can be used to inject any IP option into a
    network and cause trouble?
    
  5. Russ Housley: Discuss [2011-01-05]:
        
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
      that has not been answered.  I think that a response is needed.
    
      Joel says:
      > It is unclear in the document what assumptions section 3.1 makes
      > about the relationship between supported tunnels and checked
      > embedded addresses.  Is there an assumption that the router only has
      > to check for addresses in the format and prefix it supports?  
        
  6. Tim Polk: Comment [2011-01-05]:
    This is a useful document and I support its publication.  I believe this could
    be a better and more useful document
    if the authors could address a few issues
    before publication:
    
    Issue #1
    
    I think the intended scope of this document is not consistently stated
    (explicitly and implicitly):
    (1) the document title is "Tunneling Security
    Concerns";
    (2) the abstract states "The primary intent of this document is to
    raise the awareness level ..."
    (3) the introduction states "This document
    discusses security concerns ... and includes recommendations
    where relevant."
    (4) the introduction also states "The primary intent is to help improve security
    deployments ..."
    
    Based on the title and the abstract, I was expecting a problem statement draft.
    The first bit I quoted from the
    intro implies that this is a problem statement
    draft, and the recommendations are an afterthought.  The last bit
    says the
    recommendations are the whole point of the document.
    
    IMHO, the recommendations are the most important contribution made by this
    document.  I would like to see
    edits in the abstract and intro to clearly state
    that.  It may be too late to address the title, but "Mitigating
    Tunneling
    Security Concerns" would also clearly demonstrate that scope.
    
    Issue #2
    
    The document presents a collection of network architecture and network
    administration recommendations, 
    but readers might really benefit from some
    summary recommendations.  I was hoping for a section that 
    moved the document
    from a laundry list to a methodology of sorts that worked through the
    architectural 
    decisions first, then moved on to mitigating the specific
    problems remaining after the architectural decisions 
    are made.  For example, it
    seems that architecting your network so that tunnels don't cross security
    boundaries is a key first step.  If you don't follow that recommendation,
    everything else is harder, isn't it?
    
    Issue #3
    
    The introduction closes with "The intended audience ... includes network
    administrators and future protocol 
    developers."  I had a hard time
    understanding what the lessons are for future protocol developers.
    
    Perhaps a paragraph or two summarizing recommendations for protocol developers
    would be useful here.
    
    Issue #3
    
    Section 5.1 is conspicuous in its structure: it includes a "5.1.1 Problem", but
    omits the expected
    "5.1.2 Discussion" and "5.1.3 Recommendations".  Is it true
    that there is nothing to say here?

draft-ietf-v6ops-tunnel-loops

  1. Jari Arkko: Discuss [2011-01-05]:
        This is a good document and should be published.
    
    However, I have one concern about the described neighbor cache check
    solution. First off, the document is incorrect that hosts must
    continuously send RSes to keep their address configuration up to date.
    More importantly, the neighbor cache is just that, a cache. A better
    solution would be to probe for a neighbor and only drop the packet if
    there was no response. This is already described in the document.
    My suggestion would be to delete the neighbor cache check solution
    entirely from the document.
    
    I think it would also be great if this document made a stronger statement
    about the IMO most important use case for automatic tunnels: broadband
    home networks. These are very simple networks with just one exit router
    and it would be important to highlight the significance (or lack
    thereof) of the attack in this case & point to the recommended solution. 
        
  2. Jari Arkko: Comment [2011-01-05]:
    
        
  3. Stewart Bryant: Discuss [2011-01-05]:
        "based on protocol-41 encapsulation" needs a reference
    
    I have tried to read section 2 a number of times and I do not understand the
    loop.
    
    I do not understand what "The attacker exploits the fact that R2 does not know
    that R1 does not take part of T2" means. 
        
  4. Stewart Bryant: Comment [2011-01-05]:
    
        
  5. Adrian Farrel: Discuss [2011-01-06]:
        Having had some time to go back and re-read this document I am now not
    comfortable.
    
    1. In Figure 1, why is R2 advertising reachability to an IPv6 at all? It has
    only one point of attachment to the v6
       network. I think you are trying to say
    that there is a virtual link (v6 capable) running over the v4 network. Isn't
    that link simply part of the v6 network?
    
    2. Why is R2 advertising reachability to an address that is not reachable
    through it? You say:
          "...destined to a fictitious end point that appears
    to be reached via T2..." 
        
  6. Russ Housley: Discuss [2011-01-05]:
        
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
      that has not been answered.  I think that a response is needed.
    
      Joel says:
      > It is unclear in the document what assumptions section 3.1 makes
      > about the relationship between supported tunnels and checked
      > embedded addresses.  Is there an assumption that the router only has
      > to check for addresses in the format and prefix it supports? 
      The Gen-ART Review by Joel Halpern on 28-Dec-2010 raises a question
      that has not been answered.  I think that a response is needed. 
        
  7. Tim Polk: Comment [2011-01-05]:
    Please clarify that the document's scope does not address the Teredo attacks
    specified in the USENIX paper.
  8. Peter Saint-Andre: Comment [2011-01-05]:
    Given that the document describes an attack that can result in denial of
    service, a reference to RFC 4732 would be appropriate.

draft-ietf-l2vpn-vpls-bridge-interop

  1. Adrian Farrel: Comment [2010-03-09]:
    The new revision addresses a number of the points I raised in my review of
    11-Apr-2009. I will clear my Discuss and record the three unaddressed points
    here.
    
    Section 2
    Maybe this could use a figure. There is a lot of information conveyed
    and perhaps a figure of a VPLS showing the network and instance would
    help.
    ---
    Figure 2+
    I can sort of look at figures 1 and 2 and see a more complete picture
    of the PE model with PWs on one side and CEs on another. I think that
    in figure 2 it would help to label the ACs (C-VLANs), but it would also
    be helpful to show CE attachment when the ACs are not VLANs.
    Is there some way to give this more comprehensive picture?
    ---
    Section 9
    To me, this section feels very light. I am not a security expert,
    but the fact that you are extending an architectural model should
    give rise to new security issues for consideration.
  2. Sam Hartman: Discuss [2007-12-19]:
        Security directorate comments by Phillip Hallam-baker have not been
    addressed.  These comments were not submitted as public last call
    comments.  However they raise serious readability and interpretability
    questions of the document.  I do know that some of Phil's comments are
    wrong because I've read some of the VPLS base specs.  So, I tried to
    make an independent review of the document in order to determine if
    there was anything blocking.  However I failed to be able to
    comprehend the document well enough to follow it.  I gave up in the
    middle of section 3 with very little understanding of where the
    document was going and low confidence that the description of VPLS in
    this document matched my understanding from the base VPLS specs.
    
    To make this discuss actionable, I recommend that the authors work
    with reviewers outside their working group and improve the document to
    a point where someone who has not worked extensively in the L2VPN
    working group but who has read the VPLS documents can easily follow
    the document and can accurately describe what is going on. 
        
  3. Russ Housley: Comment [2010-03-10]:
    
        
  4. David Ward: Discuss [2007-12-20]:
        Unfort, I find the doc very, very terse and almost unable to understand the
    points that are being made and the suggested recommendations. In addition I find
    it odd that there are cases where interop needs to be "worked out." It suggests
    that an interop procedure or recommendation is incomplete and thus, the doc is
    premature. 
        

draft-loreto-http-bidirectional

  1. Sean Turner: Comment [2011-01-05]:
    Sec 8: r/attacks.[RFC4732]./attacks [RFC4732].

draft-turner-md5-seccon-update

  1. Russ Housley: Comment [2011-01-05]:
      I think this documnet would be more useful to people trying to choose
      an algorithm if Section 2 were structured to present the conclusions
      at the beginning, and then provide the details in the susbsections.  I
      suggest:
    
       MD5 was published in 1992 as an Informational RFC.  Since that time,
       MD5 has been extensively studied and new cryptographic attacks have
       been discovered.  Message digest algorithms are designed to provide
       collision, pre-image, and second pre-image resistance.  In addition,
       message digest algorithms are used with a shared secret value for
       message authentication in HMAC, and in this context, some people may
       find the guidance for key lengths and algorithm strengths in
       [SP800-57] and [SP800-131] useful.
    
       MD5 is no longer acceptable where collision resistance is required
       such as digital signatures.  It is not urgent to stop using MD5 in
       other ways, such as HMAC-MD5; however, since MD5 must not be used for
       digital signatures, new protocol designs should not employ HMAC-MD5.
       Alternatives to HMAC-MD5 include HMAC-SHA256 [HMAC][HMAC-SHA256] and
       [AES-CMAC] when AES is more readily available than a hash function.

draft-turner-md2-to-historic

  1. Adrian Farrel: Comment [2011-01-04]:
    Comment transferred from my previous process Discuss.
    
    I fully support knocking MD2 on the head. However, I am a little
    inexperienced with the process of making an I-D Historic.
    
    What happens to an standards track documents with references
    (especially normative references) to 1319 as listed in Section 3?
    Should they at least also be marked as "updated by" this draft?
    
    Similarly, 1319 updates 1115. What happens to 1115 and its text
    on MD2?
  2. Alexey Melnikov: Comment [2010-12-19]:
    Updates: 1319 (once approved)
    
     - why not Obsolete: 1319 ? This document is moving RFC 1319 to Historic.
    
    3. Documents that Reference RFC 1319 
    
       MD2 has been specified in the following RFCs:
    
    *Use* of MD2 has been specified ...
    

draft-turner-md4-to-historic

  1. Adrian Farrel: Comment [2011-01-05]:
    As with the MD2 document, I think it is worth listing the standards 
    track documents shown in Section 3 as Updated in the document header.
    
    It looks to me that you might also want to update some of the 
    informational documents listed here.
    
    The prime benefit is that those documents will be marked in the RFC
    repository as having been updated by this document.
    
    ---
    
    Abstract, etc.
    
    Once published, this document should be more assertive. Thus:
    OLD
    This document recommends RFC 1320 be moved to Historic status.
    NEW
    This document moves RFC 1320 to Historic status.
    END
    
    etc.
    
    ---
    
    4. Impact on Moving MD4 to Historic
    
    s/on/of/
    
    ---
    
    Section 4
    
       o MD4 was used in the Inter-Domain Routing Protocol (IDRP); each IDRP
         message carries a 16-octet hash that is computed by applying the
         MD-4 algorithm (RFC 1320) to the context of the message itself.
         Over time IDRP was replaced by BGP-4.
    
    Need to add a refernce to 4271, and an indication that BGP-4 requires at
    least MD-5. You could reference 2385, but that might be de trop.
    
    ---
    
    Section 4
    
       o The three Microsoft RFCs, [RFC2433], [RFC2759], and [RFC4757], are
    
    Do we need to describe these as "Microsoft RFCs"? 
    How about: "The three RFCs describing Microsoft protocols"?
  2. Alexey Melnikov: Comment [2010-12-19]:
    The document header has:
    
       Updates: 1320 (once approved)
    
    Why not "Obsoletes: 1320" ?
    

draft-irtf-mobopts-mpa-framework

  1. Ralph Droms: Comment [2011-01-06]:
    I strongly suggest that the following comments are addressed
    before publication:
    
    In section 7.3.1, a DHCP relay agent does not have the capability to
    operate independently and perform a DHCP message exchange with a DHCP
    server in anticipation of an eventual DHCP message exchange initiated
    by a client.  The mecahnism described in this section would require
    the definition of a new DHCP proxy function.
    
    In the case of IPv6, it's probably required to forward the RA to the
    mobile node regardless of the address assignment model, to
    pre-configure the mobile node with all the requisite information about
    prefixes, etc.
    
    In section 7.3.3, there is a conflict with the DHCPv6 specification,
    which requires that a DHCPv6 client send any messages to the DHCPv6
    servers/relays multicast address, rather than unicast to a server. 
    
    There may also be a problem with all of these methods using DHCP: how
    does the CTN DHCP server know what address to assign to the client?
    
    Other comments:
    
    Perhaps a nit, but I was somewhat mislead by the title, " A Framework
    of Media-Independent Pre-Authentication (MPA) for Inter-domain
    Handover Optimization" to believe that I was going to read about a
    protocol that focused on authentication and secure communication.  In
    my opinion, this document describes a complete framework for
    media-independent inter-domain handover optimization that goes beyond
    authentication and security.
    
    In Appendix A, wouldn't DAD be performed by the NAR rather than the
    PAR?
    
    From the Intro:
    
       In this document
       we discuss a framework to support terminal mobility that provides
       seamless handovers with low latency and low loss.
    
    Are there other components to terminal mobility aside from MPA?
    
    Section 1.2:
    
       A trade-off between one-way-delay and
       packet loss is desired based on the type of application.
    
    Unclear to me - a trade-off should be available through tuning or
    one-way-delay should be improved relative to packet loss?
    
    Section 3: Define "inter-subnet handover"?
    
    Section 6.1:
    
       MPA provides three basic procedures to provide this functionality.
       The first procedure is referred to as "pre-authentication", the
       second procedure is referred to as "pre-configuration", the
       combination of the third and fourth procedures are referred to as
       "secure proactive handover".
    
    "three basic procedures" and "third and fourth procedures" is
    confusing; where did that fourth procedure come from?
    
    Section 6.1:
    
       Especially, the third procedure described above (i.e., binding update
       procedure)
    
    Change "third procedure described above" to "step (iii) in the
    previous paragraph" to avoid confusion with the use of "procedures in
    the earlier paragraph in section 6.1.
    
    Section 6.2:
    
       The authentication
       protocol MUST be able to derive a key between the mobile node and the
       authentication agent and SHOULD be able to provide mutual
       authentication.
    
    Is "derive a key between ..." a term of art or can the requirement be
    described more accurately as "establish a shared key between..."?
    
       The authentication protocol SHOULD be able to
       interact with a AAA protocol such as RADIUS and Diameter to carry
       authentication credentials to an appropriate authentication server in
       the AAA infrastructure.
    
    Does the authentication protocol interact directly with the AAA
    protocol, or does the interaction happen through the AA?
    

draft-templin-iron

  1. Jari Arkko: Comment [2010-12-16]:
    
        
  2. Stewart Bryant: Comment [2010-12-15]:
    I am surprise that the document contains no reference to LISP which is
    operating broadly in this space.
    
    =======
    
    SRA is not a defined abbreviation.
    
    =======
    
    This needs a few words of clarification - presumably the "locator addresses" are
    the addresses learned from the relay.
    
      After the Client receives an SRA message from the nearby Relay
       listing the locator addresses of nearby Servers, it sends SRS test
       messages to one or more of the locator addresses to elicit SRA
       messages.
    
    =======
    				   
    If this Server fails, the Client will quickly select a new
       one which will automatically update the VPC overlay network mapping
       system with a new EP-to-Server mapping.
    
    "quickly" is a non-specific metric
    
    =======
    
    [I-D.templin-intarea-seal] looks like it should be normative
    [I-D.templin-intarea-vet]  looks like it should be normative
    
    Although the RFCeditor may wish to overlook this if there is a concern that
    these drafts will not be taken to completion.
    
    
  3. Ralph Droms: Comment [2010-12-16]:
    I have one suggestion about the content of the document.  I'd like to
    see an analysis of how IRON actually "provide[s] scalable PI
    addressing without changing the current BGP [RFC4271] routing system"
    along with costs incurred by IRON.  How does hiding the EPA addresses
    inside the IRON locator prefixes reduce the routes in the real
    Internet core?  What is the cost in the routing tables maintained by
    the relays?  How expensive is the anycast routing?  How does inter-VPC
    routing work and how expensive is it?
    
    The remainder of my COMMENTs are editorial.
    
    In Section 6.1, I think I understand what this text is trying to
    explain, but I don't think it's correct:
    
       It
       is therefore essential that the Client send the initial packets
       through its Server to avoid loss of SCMP messages that cannot
       traverse a NAT in the reverse direction.
    
    Does this mean to explain that the Client sends packets through its
    Server to establish NAT state so SCMP messages from the Server to the
    Client can traverse the NAT?
    
    In Section 6.2, this text uses "into the Internet" in a confusing way,
    assuming I'm understanding the meaning of the text correctly:
    
       The Server then
       forwards the revised packet into the Internet via a default or more-
       specific route, where it will be directed to the closest Relay within
       the destination VPC overlay network.
    
    Everywhere else in this section "into the Internet" is used to
    describe the forwarding of a decapsulated datagram, after the outer
    header with locator addresses have been removed, into the (non-IRON)
    Internet.  In the text quoted aboce, "into the Internet" seems to mean
    forwarding of an encapsulated datagram, which is described elsewhere
    in this section as simply "forwards" or "sends".  I suggest rewriting,
    for consistency, as
    
       The Server then
       forwards to the closest Relay within
       the destination VPC overlay network.
    
    In Figure 6, why would the anycast datagram from Server(A) be
    delivered to Relay(B) rather than Relay(A) (which presumably would be
    in the routing fabric for ISP A)?  Does it matter? 
    
    Once Server(B) receives the datagram to be forwarded to Client(B), is
    it possible for Server(B) to send a redirect to Client(A) so Client(A)
    can send traffic directly to Client(B)?
    
    Stylistic nit in section 6.4.1 (and elsewhere) - why start using the
    verb "releases" instead of the previously used "forwards" or "sends"?
    Seems like lots of unnecessary verbiage right after Figure 6; why not
    something like "..., host A sends packets to host B through its EUN.
    Client(A), as the defautl router for the EUN, receives the packets,
    encapsulates them in the IRON encapsulation and forwards them to
    Server(A). ..."  (etc.)  All the explanation of routing, etc., seems
    redundant at this point.
    
    Sorry, can't help myself; in section 6.6:
    
       The IRON approach to
       renumbering avoidance therefore depends on VPCs conducting ethical
       business practices and offering reasonable rates.
    
    ... as opposed to the unethical business practices and unreasonably
    high rates from those evil, greedy ISPs.
    
    Seriously, has the renumbering problem simply been moved from the ISPs
    to the VPCs?
    
  4. Adrian Farrel: Comment [2010-12-16]:
    Thank you for bringing this work forward as Experimental and so increasing the
    documentation and discussion of potential solutions.
    
    I feel that it would be helpful if the document contained a pointer to draft-
    irtf-rrg-recommendation so that the other ideas in the field can be easily found
    and compared.