IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2012-07-19. These are not an official record of the meeting.

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

Corrections from: Martin, Barry

1 Administrivia

  1. Roll Call 1134 EDT 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. Kerberos Options for DHCPv6 (Proposed Standard)
    draft-sakane-dhc-dhcpv6-kdc-option-17
    Token: Stephen Farrell
    Note: The Document Shepherd for this document is Jeffrey Hutzelman, (jhutz@cmu.edu).
    Discusses/comments (from ballot draft-sakane-dhc-dhcpv6-kdc-option):
    1. Adrian Farrel: Comment [2012-07-19]:
      Would you mind rewriting the Abstract for clarity? Something like...
      "This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry coniguration information for Kerberos."
    2. Barry Leiba: Comment [2012-07-14]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      -- Section 4 --
      I find the use of 2119 language a bit odd in the second and third paragraphs. You use MUST for what the client sends to the server, and you don't use 2119 language for how the server responds. In fact, I think it would be fine to strike the MUSTs from the client side too. For example, this works fine for the third paragraph:
      "If a client requires configuration parameters for a KDC, the client sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client MAY include a Kerberos Principal Name Option. The client MAY include a Kerberos Realm Name Option."
      That makes it parallel to the protocol instructions for the server.
      I also find the MUST in the fifth paragraph to be odd, but it matches the 2119 language in RFC 2782, so I can't really pick any bones with it.
      The MUST in Section 4.1 is stranger still:
      "The administrator of the realm MUST define the method as part of the configuration of the client before the client is installed."
      I don't know how that qualifies as a MUST, how it has anything to do with interoperability, nor how it could be detected or enforced. Wouldn't it be suitable to just say that "the administrator of the realm usually defines the method [...]" ?
      -- IANA Considerations --
      "The assignment of future entries is by "IETF Consensus" policy as described in BCP 26 [RFC5226]."
      In RFC 5226 this is called "IETF Review", not "IETF Consensus"; please change that.
    3. Pete Resnick: Comment [2012-07-18]:
      I agree with Barry's concerns. Please address them.
    4. Martin Stiemerling: Comment [2012-07-17]:
      [updated, as the IANA part takes care all of stuff to be registered.]
      Please reply to these comments, as they are substantial for the document:
      Section 3., paragraph 7: "With the exception of the Kerberos KDC Option, none of these options may appear more than once in a DHCPv6 message."
      Shouldn't this read 'MUST NOT appear'?
      Appendix B., paragraph 1: "When no criteria have been specified and the client could get the Kerberos information from either the DNS server or the DHCPv6 server, then the information from DNS should be preferred. The following is the guideline for the client in such an environment."
      This appendix is not meant to be the standard, but rather informational, isn't it? If it is this way, please state it explicitly!
    5. Sean Turner: Comment [2012-07-18]:
      Updated based on email exchange with Sam.
      (12 items)

    Telechat:

  2. Common requirements for Carrier Grade NATs (CGNs) (Best Current Practice)
    draft-ietf-behave-lsn-requirements-08
    Token: Wesley Eddy
    Note: Dan Wing (dwing@cisco.com) is the document shepherd.
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-behave-lsn-requirements-04
    Discusses/comments (from ballot draft-ietf-behave-lsn-requirements):
    1. Ronald Bonica: Discuss [2012-07-13]:
      Section 5, as it is currently composed, strays from requirements into potential solutions.
      From the perspective of a requirements document, Section 5 is really about:
      - a port utilization requirement
      - a log volume requirement
      - a security / port guessing requirement
      All of these should be called out as real requirements (REQ-xx). A discussion of these requirements should mention that they compete with one another. An implementation optimizes to satisfy one requirement at the expense of another. Therefore, these are soft requirements (SHOULD as opposed to MUST).
      It might be OK to mention that an implementation's choice of port allocation scheme influences which requirement gets priority. However, when we mention three specific port allocation schemes (traditional, scattered and consecutive) we put one toe out of bounds. When we make statement about which scheme optimizes for which requirement, the rest of the body follows the toe.
      Honestly, I would have never noticed this problem had it not been for the IPR declaration and the authors assumption that the IPR related to Section 5. But one closer examination, the section has a problem, regardless of the IPR.
    2. Ronald Bonica: Comment [2012-07-18]:
      Agree with Russ that this document should be INFORMATIONAL
    3. Stewart Bryant: Comment [2012-07-17]:
      I agree with Russ's DISCUSS concerning the classification of this document as BCP. Informational seems more appropriate.
      Why does REQ-1 not also specify draft-ietf-behave-sctpnat-06?
      Limiting the rate of allocation is intended to prevent against CPU resource exhaustion.
      d/against/
      REQ-12: A CGN SHOULD NOT log destination addresses or ports.
      Justification: Destination logging at the CGN creates privacy issues.
      Why is this not "SHOULD NOT log destinations addresses or ports unless required to do so for administrative reasons" followed by privacy advice?
      As much as the IETF finds it distasteful, this sort of logging may well be administratively required at number of levels, and we should deal with minimizing the privacy issues when this happens.
    4. Ralph Droms: Discuss [2012-07-16]:
      I want to discuss the indication that this document updates RFC 4787. My position does not require any changes to the document by the authors at this time.
      In my opinion, this document builds on RFC 4787 to list requirements for use cases or deployment scenarios not in the scope of RFC 4787, but does not update or replace any of the text in RFC 4787. While a couple of requirements in this document are described as "stronger versions" of the corresponding requirements from RFC 4787, I don't see any indication that these modified requirements are to be retroactively applied to RFC 4787.
      If it does update RFC 4787, exactly what text in RFC 4787 updated with new text from this document?
    5. Stephen Farrell: Discuss [2012-07-14]:
      (1) As written, REQ-1 is followed by a MUST that applies to anyone who ever writes a NAT-considerations for any transport protocol for all time. (Even though CGN is presumably a transition technology intended to vanish in a decade or so when IPv6 is everywhere.) That seems wrong in lots of ways. In fact it seems backwards. Oughtn't the onus be on CGN folks to update to meet the needs of new transports and not the other way around and oughtn't CGN be designed so as to work (to the maximum extent possible) with any transport that we can now envisage. If in fact its not possible for a GGN to be designed to be friendly towards future transport networks, then the argument that that is the case needs to be made. (And be convincing if you want the MUST this way about.) I'm not sure what kind of change might help out here but I think some change is needed.
      (2) REQ-4 calls for "limits ... per transport protocol" in bullet B. Is that meant to be per-subscriber? If so, why are you limiting how a subscriber chooses to use their bandwidth on a per-transport protocol basis? If not, then it really seems like a different requirement that is not part of REQ-4 and is very odd - why would a CGN want the set of subscribers behind it to use e.g. 50% less UDP than TCP?
      (3) Does REQ-7 mean "CGNs SHOULD use EIF"? Its not clear to me if you mean that, or if you mean "CGNS SHOULD implement EIF"? I think "RECOMMENDED [to] ... have... behaviour" is ambiguous.
      (4) cleared
      (5) I agree with the changes suggested by Sam Hartman in his secdir review for REQ-9 and section 8. Sam suggested text that'd work for me, and the authors seem receptive but I'm not clear if the discussion has converged or not. (I expect it will, so this mainly for tracking.)
    6. Stephen Farrell: Comment [2012-07-14]:
      (7 items)
    7. Brian Haberman: Comment [2012-07-12]:
      1. In section 3, the text states "If NAT behavioral requirements documents are created for additional protocols, then these new documents MUST update this list by adding themselves to it." Do these new behavioral requirements documents need to update this document? Does this document need to be updated each time a new behavioral document is published as an RFC?
      2. For REQ-6, what is the impact of disabling translation on state tables within the NAT? If no state is maintained, is there a DoS vulnerability for the client? For example, if I know that traffic from X2:x2 --> X1:x1 is not translated, could I use that knowledge to attack the client?
      3. REQ-8 recommends not re-using a port until 120 seconds elapses. Is that value applicable to all transport protocols? How do you envision a CGN enforcing that value after a crash (as mentioned in the last paragraph of the requirement justification)?
    8. Russ Housley: Discuss [2012-07-14]:
      In the Gen-ART Review by Alexey Melnikov on 3-July-2012, he asked:
      "I found it is to be odd to have a requirements document as a BCP, but I am sure you can sort the right status out with IESG."
      The authors made no attempt to encourage the publication as BCP. They appear to be satisfied with either BCP or Informational. Requirements documents are normally published as Informational RFCs. I see no reason for an exception in this case.
    9. Barry Leiba: Comment [2012-07-11]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      -- REQ-5 --
      "It is at the SHOULD level to account for the fact that means other than rate limiting may be used to attain the same goal."
      It seems, then, that there is a higher-level requirement that's missing, and that this "requirement" is really stating a suggested means to achieve it.
      UPDATE: Simon explains that "It" in the above quotation refers to list item B only. I'm requesting that he change "It" to "Item B" to make that clear.
      "This state consumes resources for which, in the case of a CGN, subscribers may compete. It is necessary to ensure that each subscriber has access to a fair share of the CGN's resources. Limiting TCP sessions per subscriber and per time unit is an effective mitigation against inter-subscriber DoS attacks."
      UPDATE: Simon also explains that the last sentence in the paragraph above needs to be removed.
    10. Pete Resnick: Comment [2012-07-17]:
      For the IESG: Perhaps I'm just being contrarian today, but I *do* think this document should be BCP and not Informational. It is not a requirements document in the sense that it is laying out requirements for future protocol documents being developed by a WG; it is a consensus document listing the requirements for the operation and administration of a type of device. If that doesn't fall within the 2nd paragraph of RFC 2026 section 5, I don't know what does.
      For the authors/WG: I agree with Stephen's point about REQ-1, but disagree with the solution suggested on the IESG list; I think it reversed the sense of the statement. You had:
      OLD: If NAT behavioral requirements documents are created for additional protocols, then these new documents MUST update this list by adding themselves to it.
      NEW: Any future NAT behavioral requirements documents for IPv4 transport protocols will also need to consider the requirements for CGNs stated here.
      But this loses the sense that new NAT behavioral requirements documents will impose new requirements on CGNs. Might I instead suggest:
      "Any future NAT behavioral requirements documents for IPv4 transport protocols will impose additional requirements for CGNs on top of those stated here."
      The requirement is not a requirement for future documents; it's a requirement for CGNs.
    11. Robert Sparks: Comment [2012-07-18]:
      I share Ralph's question about how this updates RFC4787.
      It worries me that we are requiring the implementation of a new protocol (pcp) as part of a BCP. It would be more work to write "you need to do all the things pcp lets you do", but it would be more in the spirit of RFC4787 to have done so.
    12. Martin Stiemerling: Discuss [2012-07-17]:
      Updated my position, after reading REQ-9 again:
      Section 3., paragraph 42: "REQ-9: A CGN MUST include a Port Control Protocol server [I-D.ietf-pcp-base] with the following constraints on its behavior:"
      Is this saying that each and every CGN MUST have PCP or that CGN implementing PCP must follow the constraints?
      "Each and every CGN MUST have PCP and MUST follow the constraints. I'll fix the text in a later revision."
      Can we mandate a specific protocol to be used for this or can we only mandate that such a type of protocol is being used? I don't see the IETF in the position to mandate this type of protocol for CGNs.
      There are other protocols out there which might be suitable. Note that I am co-author of some, but this isn't the reason for the question. I do not get any reward if I promote these protocols.
      It is more: do we need to constrain CGN deployments to a protocol (PCP) which is developed right now, or are we open to existing or future protocols, or whatever folks deploying this deem right?
      I would propose to change REQ-9 to :
      "REQ-9: A CGN MUST include a middlebox control protocol that allows manipulation of CGN bindings with the following contstraints <list items A and B>
      "REQ-9a: If PCP is used these contstraints MUST be applied in addition to contraints A and B: <list items C and D>"
    13. Martin Stiemerling: Comment [2012-07-18]:
      I am fine with this being BCP. (the prior version of the ballot was a typo)
      Section 3., paragraph 50: "REQ-10: CGN implementrers SHOULD make their equipment manageable. Standards-based management using standards such as "Definitions of Managed Objects for NAT" [RFC4008] is RECOMMENDED.
      s/implementrers/implementers/
    14. Martin Stiemerling: Comment [2012-07-17]:
    15. Sean Turner: Discuss [2012-07-18]:
      1) s4: Shouldn't the requirements for the timestamp be identical to the requirement in 6302:
      "A timestamp, RECOMMENDED in UTC, accurate to the second, from a traceable time source (e.g., NTP [RFC5905])."
      2) s4: doesn't transport protocol need to be added to the list?
    16. Sean Turner: Comment [2012-07-18]:
      s4: Because you gave an out in the previous paragraph it's worth noting in the following that one reason might be that the CGN isn't following 6302:
      "This requirement is at the SHOULD level to account for the fact that there may be other reasons for logging destination addresses or ports."

    Telechat:

  3. Transmission of IPv6 Packets over Bluetooth Low Energy (Proposed Standard)
    draft-ietf-6lowpan-btle-08
    Token: Ralph Droms
    Note: Carsten Bormann (cabo@tzi.org) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-6lowpan-btle):
    1. Stewart Bryant: Discuss [2012-07-17]:
      Bluetooth Special Interest Group [BT-SIG] has introduced two trademarks, Bluetooth Smart for single-mode devices (a device that only supports BT-LE) and Bluetooth Smart Ready for dual-mode devices.
      If these are trademarks, as opposed to device class names, have we represented the trademarked name in the legally accepted format? Do we need to represent "Bluetooth" in a format to identify it as a trademark term?
    2. Wesley Eddy: Comment [2012-07-17]:
      Figure 3 seems to suggest that TCP or UDP are the only supported transports, and that there are no applications above them, or other tunneling possible. I think the figure should just show a generic "upper layer protocols" blob on top of IPv6, or just end the stack at IPv6 unless the capability is really restricted to just TCP and UDP, no ICMPv6, etc., which doesn't seem right.
    3. Adrian Farrel: Comment [2012-07-19]:
      On the whole, I am supportive of this document, and there are enough Discusses covering the main issues. Please consider my Comments some of which may help resolve those Discusses.
      I am a little confused about the difference between "Bluetooth 4.0" and "BT-LE."
      The Abstract adds to this confusion...
      "The low power variant of Bluetooth is commonly specified in revision 4.0 of the Bluetooth specifications and commonly refered to as Bluetooth 4.0."
      1. s/commonly specified/currently specified/ ?
      2. Is the low power version of Bluetooth commonly refered to as Bluetooth 4.0 as the text appears to say? If so, why do you consistently refer to BT-LE instead?
      Section 2, on the other hand, suggests that BT-LE is only a part (albeit integral) of the Bluetooth 4.0 spec.
      I see no reason to refer to the "Bluetooth Smart" and "Bluetooth Smart Ready" trade names. Only one is used in the document, and could easily be replaced with real text. Cleaning this up would avoid the issues of:
      - a reference that is a URL and not a pointer to a document
      - the whole trademark issue
      Section 2.3: "This specification mandates that the Bluetooth Device Address MUST be a public address."
      As phrased, this implies that you are changing the BT 4.0 spec (which is not your intention and would not go down well!). I think what you mean is:
      "This specification mandates that Bluetooth devices transmitting IPv6 packets in conformance with this specification MUST use a Bluetooth Device Address that is a public address."
      Section 3.1 and Section 4
      I do not think this document should attempt to specify (or discuss) code points that will be allocated by other bodies.
    4. Stephen Farrell: Discuss [2012-07-16]:
      In figure 5 the 6LBR is the BTLE-Master and the gateway to the Internet, which is a reasonable choice, but why is it the only choice? Are there no scenarios where a BT-LE slave wouldn't have another i/f and so be able to act as a g/w to the Internet, e.g. when the BTLE-Master doesn't have an Internet connection? Why rule that out? There may well be good reasons but it wasn't clear to me.
      I guess another way to ask this is to ask why you can't support this diagram: (see link)
    5. Stephen Farrell: Comment [2012-07-16]:
      (9 items)
    6. Brian Haberman: Discuss [2012-07-18]:
      I support the publication of this document, but there are some issues that need to be DISCUSSed...
      1. This is probably related to Stephen's DISCUSS on which types of nodes can act as Internet gateways. The second paragraph of Section 3 says that BT-LE does not support the formation of multihop networks. I assume this is implying multihop at the Bluetooth layer and not the IP layer since the spec later talks about forwarding IPv6 packets between master nodes. This should be stated more clearly in the text. As a follow-on, does this multihop limitation also mean that slave nodes can only have a single interface (thus eliminating Stephen's alternative gateway location architecture)?
      2. Section 3.2.1 states that IPv6 over BT-LE will perform SLAAC as defined in RFC 4862. Given the limited topology of BT-LE, is there a reason to perform all of 4862? Since section 3.2.2 requires a node to register its address with the master, is there a need to perform DAD on the point-to-point link between the master and slave? The 802.15.4 spec needs that capability because of the potential to operate in a mesh topology, but it really isn't needed in the star topology.
      3. Related to Sean's DISCUSS on header compression... The opening sentence of section 3.2.3 does not make sense. Why does it say "This document assumes [RFC6282]..."? As a protocol specification, it specifies what is to be used. Something along the lines of "Header compression, as defined in RFC 6282 is REQUIRED..." would be more appropriate.
    7. Brian Haberman: Comment [2012-07-18]:
      (5 items)
    8. Russ Housley: Discuss [2012-07-17]:
      I have selected portions of the Gen-ART Review from Brian Carpenter that meet the DISCUSS Criteria. From my perspective, it would have been much simpler for the authors to respond to these comments when they were first posted during IETF Last Call.
      (1) Section 3.1 includes this paragraph:
      "In order to enable transmission of IPv6 packets over BT-LE, a new fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT-SIG. A request for allocation of a new fixed channel ID for IPv6 traffic by the BT-SIG should be submitted through the liaison process or formal communique from the 6lowpan chairs and respective area directors. Until a channel ID is allocated by BT-SIG, the channel ID 0x0007 is recommended for experimentation. Once the channel ID is allocated, the allocated value MUST be used."
      Let's wait for needed L2CAP Channel ID to be allocated, and then publish a standards-track RFC.
      (2) Section 3 includes this paragraph:
      "BT-LE technology sets strict requirements for low power consumption and thus limits the allowed protocol overhead. 6LoWPAN standards [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic functionality like header compression, link-local IPv6 addresses, Neighbor Discovery and stateless IP-address autoconfiguration for reducing the overhead in 802.15.4 networks. This functionality can be partly applied to BT-LE."
      This is not the Introduction section, when an unclear statement like this might be acceptable. Three normative references are provided, but we are told that they are "partly applied". An implementer is not given enough information to build interoperable implementations. Brian suggested text; however, I would strongly prefer a pointer to a subsection for each normative reference.
    9. Barry Leiba: Discuss [2012-07-11]:
      This is a procedural issue:
      -- Section 3.1 --
      "In order to enable transmission of IPv6 packets over BT-LE, a new fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT-SIG. A request for allocation of a new fixed channel ID for IPv6 traffic by the BT-SIG should be submitted through the liaison process or formal communique from the 6lowpan chairs and respective area directors. Until a channel ID is allocated by BT-SIG, the channel ID 0x0007 is recommended for experimentation. Once the channel ID is allocated, the allocated value MUST be used."
      1. The first MUST is inappropriate: we don't have any standing to make a normative requirement on the BT-SIG. What you *mean*, I think, is simply that we have to get a channel ID allocation (a demand on the 6lowpan chairs, I guess, to handle that), and then we MUST use it (the second MUST covers that part).
      2. Has this request been made? If so, what is its status (neither the document nor the shepherd writeup says)? If not, when is that planned to happen? Should I hold this DISCUSS as a reminder for it to be done? Or does that request have to wait until after this document is published (in which case, how do we track it)?
      3. Does it fit into BT-SIG's procedures to use 0x0007 for now, or are we proposing to "squat" on one of their code points with that recommendation, in a way they would disapprove of?
    10. Barry Leiba: Comment [2012-07-11]:
      Non-blocking, and no need to respond to these: (two items)
    11. Pete Resnick: Comment [2012-07-17]:
      Section 2 is generally an overview of BT-LE. I'm not a big fan of doing technology overviews in specifications; I say just get to the protocol and give a reference or appendix for overviews.
      That said, I worry that there are 4 MUST/MUST NOT requirements in 2.3 and 2.4. If people see section 2 as purely overview, they may miss these requirements. I'd suggest moving the requirements into section 3 (the specification) to make sure that nobody misses them.
    12. Martin Stiemerling: Comment [2012-07-17]:
      In full support of Barry's point on Section 3.1.
    13. Sean Turner: Discuss [2012-07-17]:
      So this is probably a lame discuss, but I can't figure it out. In s3.2.3, you say "all headers MUST be compressed according to HC base encoding". But, in RFC 6282 there's IPHC, HNC, and IPv6 Header Encoding. Which one is the HC base encoding? Is it the one in s3.2.1 (IPv6 HE), which is referenced later in the section?
    14. Sean Turner: Comment [2012-07-17]:
      1) I support Adrian's discuss.
      2) I liked Pete's suggestions too.
      3) typos the secdir reviewer noted:
      gateway^1s => gateway's
      respectively => respectively
      5) s5: Any chance for specific references to were the BT-LE LL security and SMP are defined? Is it part of the core?

    Telechat:

  4. BGP Support for Four-octet AS Number Space (Proposed Standard)
    draft-ietf-idr-rfc4893bis-07
    Token: Stewart Bryant
    Note: John Scudder (jgs@juniper.net) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-idr-rfc4893bis):
    1. Benoit Claise: Comment [2012-07-11]:
      I would like to see the addition of section on the "manageability impact" of this change. Actually, the news are good in this case.
      1. BGP-4 MIB module. This is taken care of (as far as I can tell), because the TC took care of the
      [snip: see link]
      Note: not sure many people are actually using this MIB module, but that's behind the point.
      2. IPFIX. This is taken care of, as http://www.iana.org/assignments/ipfix/ipfix.xml defines the max length. (See bgpSourceAsNumber and bgpDestinationAsNumber ), and the Template Record defines the length, so 2 or 4 bytes.
      3. YANG. I don't believe there is anything BGP YANG module.
    2. Adrian Farrel: Comment [2012-07-15]:
      I'm happy to support this document. I am in agreement with Barry that Appendix A is a disappointment. I think it would be helpful to boost this section with some more details.
    3. Barry Leiba: Comment [2012-07-11]:
      It's always helpful, when reviewing a "bis" document, to have a summary of changes. So I was happy to see this, at the end of the Introduction:
      "This document obsoletes RFC 4893, and a comparison with RFC 4893 is provided in Appendix A."
      Imagine my dismay, then, when I trotted down to Appendix A and found that it has but one, low-content sentence:
      This document includes several clarifications and editorial changes, and specifies the error handling for the new attributes."
      If that's all you had to say, you should have just put it into the Introduction in the first place. Grumble.
      Happily, there's DIFF. :-)
      And no, don't bother changing it now. No objection, really, in any case. Just me being slightly grumpy.
    4. Pete Resnick: Comment [2012-07-16]:
      Agree with Barry and Sean.
      I hope (expect) to see this document back on the IESG agenda soon moving to Internet Standard.
    5. Robert Sparks: Comment [2012-07-16]:
      I had the same question as Sean.
    6. Martin Stiemerling: Comment [2012-07-16]:
      I'm fine with this document, but I have to second Barry's comment about Appendix A.
    7. Sean Turner: Comment [2012-07-18]:
      Thanks for addressing my discuss.

    Telechat:

  5. A GSS-API Mechanism for the Extensible Authentication Protocol (Proposed Standard)
    draft-ietf-abfab-gss-eap-08
    Token: Stephen Farrell
    Discusses/comments (from ballot draft-ietf-abfab-gss-eap):
    1. Barry Leiba: Comment [2012-07-18]:
      Just one small thing about the IANA Considerations: The reference to "section 4.1 of RFC 4121" makes it clear, but it would be useful if one detail of the registry in 7.2 were specified here... the "ID" field is two octets, specified in hex in big-endian order. Having that bit here will make it easier for IANA to see that IDs have been specified correctly, without their having to go look in RFC 4121.
    2. Sean Turner: Comment [2012-07-18]:
      Only nits: (ten items)

    Telechat:

  6. Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status (Best Current Practice)
    draft-ietf-dnsext-dnssec-algo-imp-status-03
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@anvilwalrusden.com) is the Document Shepherd
    Discusses/comments (from ballot draft-ietf-dnsext-dnssec-algo-imp-status):
    1. Adrian Farrel: Comment [2012-07-18]:
      I am Abstaining on this document. I have no specific objection to its publication, but it is so much not the document I would have written, and I struggle to see its value as currently presented.
      I was left wondering whether it is trying to do the wrong thing. Instead of tying to mandate what must or must not be implemented it would be more helpful to me to state the usage profile of each algorithm. This could then be traced to "dangerous to deploy" or "must be implemented if your implementation is to play a part in the deployment of this function."
      Anyway, here are some thoughts and comments that arose...
      Citing conformance to this document is confusing because nearly all of the information in the table in Section 2.2 indicates a degree of choice. Conformance can only be interpretted with respect to the "must" and "must not".
      To say that the "IANA registry for these algorithms ... lacks the implementation status of each algorithm"implies that this information should be recorded in the registry. It should not since that is not the purpose of the registry.
      How about...
      "There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm."
      I think Section 1 should observe that it is the intention to issue replacements to this document when the implementation status of any algorithm changes and when new algorithms are introduced.
      "This implementation status indication is only to be considered for implementation, not deployment or operations."
      I can't extract meaning from this! If something is marked "MUST NOT" implement, how can it possibly be deployed?
      Since this document makes no requests for IANA allocations and makes no changes to the existing registries, I see no reason for it to be listed in the registry. The IANA registry tracks code points, it is not a repository for documentation references.
      I can't square the statement in the Security Considerations section with the MUST NOT implement status assigned to RSAMD5. Maybe a reference is needed for the classification of RSAMD5 and that would keep Section 4 honest.
    2. Stephen Farrell: Comment [2012-07-14]:
      I can't parse this:
      "It is believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace older algorithms (e.g. RSA/SHA-1) that have a perceived weakness or these recommended algorithms are seen in major deployments."
      I guess something's wrong but hard to know what, maybe s/or/or as/
    3. Brian Haberman: Comment [2012-07-13]:
      I agree with Barry that a discussion is needed as to why an IANA registry cannot capture the necessary information.
    4. Barry Leiba: Comment [2012-07-13]:
      Former DISCUSS, leaving it here for the record.
      In principle, I like the idea of preventing fragmentation of the documentation by keeping the Section 2.2 table in one place, and by always replacing the document that has it with another, in its entirety.
      Only... isn't that what the IANA registry is supposed to be for? Why isn't that table just added to the IANA registry, and then maintained there? Doesn't this document now require us to OBSOLETE this document and replace it every time we want to change the registry?
      Update 1
      I had no idea of the history of this, until Andrew pointed me at this: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ballot/
      I need to talk this over with Pete, Robert, and Russ, at least, on the telechat, and understand why we think we can't use the IANA registry the way registries are meant to be used.
      Update 2
      After more discussion with the chairs, here's what I understand...
      1. The conformance table needs to be normative, stable, and with maintained history. It needs to be clear, when you say you conform as of [date X], what it is that you claimed to conform to. You can conform to an RFC, because once it's published, you have a stable, immutable reference, and you can give the RFC number. But if I asked you whether something conformed to the RRTYPEs registry, you'd have to ask "at what date?" And IANA doesn't maintain a history.
      2. The conformance table is necessary in the first place because as things stand, you can say you "implement DNSSEC" when (for instance) you don't do NSEC3. That's not going to be very useful, given that .com, .net, and .org are all using NSEC3. We need a single document to which people can point and say, "We do it the way that says to."
      3. If it takes an RFC to update the registry, then any change to the table needs an RFC anyway. Thus, I suppose there's no *harm* in just publishing the table in the RFC and not in the registry. I do like that the basic table is still in the registry, and that this just extracts the conformance criteria into an RFC-maintained table.
      There's no point now, but it would have helped if, especially given the history of the earlier document, some of this information had been in the shepherd writeup. But now that I understand the issues, I'm OK with this method of handling it.
    5. Pete Resnick: Discuss [2012-07-14]:
      Section 1: "This implementation status indication is only to be considered for implementation, not deployment or operations. Operators are free to deploy any digital signature algorithm available in implementations or algorithms chosen by local security policies. This status is to measure compliance to this document only."
      I think the above paragraph is either wrong or meaningless. I don't know what it means to say that the implementation status is for implementation but not deployment. The reason that one "MUST IMPLEMENT" RSASHA1 is that an implementation will not interoperate with other DNSSEC deployments if it doesn't allow the use of RSASHA1. Similarly, the reason it is "RECOMMENDED TO IMPLEMENT" RSASHA1-NSEC3-SHA1 is that you won't interoperate in DNSSEC if you don't do it, but there are circumstances under which you might not use it. The reason you "MUST NOT IMPLEMENT" RSAMD5 is because it is a broken algorithm and use of it will cause damage. These are not about implementation; they are absolutely about interoperation. Operators *are* free to deploy anything they like, but that's because there are no protocol police and you are free to ignore the considered consensus of the IETF. But the considered consensus of the IETF is that these are protocol requirements to allow for interoperation. The IETF is *not* supposed to be writing compliance documents. Please strike the paragraph in it's entirety. See next bit on 2119 keywords for more on this.
      Section 1.1:
      2119 keywords are used as part of the implementation status. This is awfully confusing because you lose the meaning of the 2119. Please (a) title case the implementations status throughout Section 2 by changing, e.g., MUST IMPLEMENT to "Must Implement", etc. and then (b) define the terms in section 1.1:
      The implementation statuses used in this document are defined as follows:
      - "Must Implement" means that the algorithm MUST be used in order to interoperate with other implementations on the Internet.
      - "Must Not Implement" means that the algorithm MUST NOT be used so as to prevent the compromise of the DNS data; the algorithm has known weaknesses and is not considered safe to use anymore.
      - "Recommended To Implement" means that the algorithm SHOULD be used in order to interoperate with other implementations on the Internet, though there may be exist valid reasons in particular circumstances not to do so. An implementer must understand and weigh the full implications of choosing not to implement this particular algorithm.
      - "Optional" means that the algorithm MAY be implemented, but that all implementations MUST be prepared to interoperate with implementations that do or do not implement this algorithm.
      Section 2.2: "Their implementation (or lack thereof) therefore cannot be included when judging compliance to this document."
      Strike this sentence. Again, it is meaningless in the context of an IETF document. This document should only talk about interoperability requirements.
      With regard to the status and title of this document:
      I believe in the normal course of events, each time a new document with a list of statuses is published, we will get implementation experience with the statuses to determine if they are correct. When we do, we can advance the document to indicate that, yes, we are sure that implementations have now taken up this new document and it is considered the standard way to implement. I therefore think that this document should be standards track instead of BCP. Indeed, the title of "Applicability Statement" I think is exactly right, and it's using the term as 2026 envisioned, which puts this on the standards track.
      If there is for some reason not consensus to move this to the standards track, I think a change of title and abstract are in order. "Applicability Statement" gets used in an odd way in the IETF (and in 2026 in particular), and I think using it for a BCP will add to our overall confusion. But I still believe that this is appropriate to the standards track.
    6. Pete Resnick: Comment [2012-07-14]:
      (three items: see link)
    7. Robert Sparks: Comment [2012-07-18]:
      I support Pete's suggestion to make this standards track.
    8. Martin Stiemerling: Comment [2012-07-16]:
      A nit: (one item)

    Telechat:

  7. DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates (Proposed Standard)
    draft-ietf-dnsext-dnssec-registry-update-03
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@anvilwalrusden.com) is the Document Shepherd

    Discusses/comments (from ballot draft-ietf-dnsext-dnssec-registry-update):
    1. Adrian Farrel: Comment [2012-07-15]:
      It is entirely unimportant, but I think most if not all references could be Informational rather than Normative.
    2. Barry Leiba: Comment [2012-07-09]:
      A nit: you've misspelled "Hellman" (as "Hellmen") in the Introduction.

    Telechat:

  8. Indicating Email Handling States in Trace Fields (Proposed Standard)
    draft-ietf-appsawg-received-state-04
    Token: Barry Leiba
    Discusses/comments (from ballot draft-ietf-appsawg-received-state):
    1. (none)

    Telechat:

  9. DNS Certification Authority Authorization (CAA) Resource Record (Proposed Standard)
    draft-ietf-pkix-caa-11
    Token: Sean Turner
    Note: Steve Kent (kent@bbn.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-pkix-caa):
    1. Ralph Droms: Comment [2012-07-18]:
      I agree with the points raised by Barry and Russ.
      Building on one of Stephen's comments: are the requirements for archiving DNS transactions regarding CAA based on actual audit requirements or are they speculative? Why would this document include those specific requirements instead of a more general statement about "meeting audit requirements" from whatever audit process is employed?
      Minor editorial suggestion: in section 3, I think you should cite more than just RFC 1035 as references for CNAME and DNAME processing.
    2. Adrian Farrel: Comment [2012-07-19]:
      I have no objection to the publication of this document and only a couple of (well, four) trivial obeservations.
      Would be nice to add just a couple of words to what is otherwise a good Abstract to say what this document actually does.
      The RFC editor will probably want to work with you to move the Introduction to be the first section in the document.
      I don't think Section 6.3 should be a subsection of Section 6!
      Are you sure that you dn't want an IANA registry for the Flags field defined in Section 4.1?
    3. Stephen Farrell: Comment [2012-07-16]:
      (18 items)
    4. Brian Haberman: Discuss [2012-07-18]:
      Many of these points come out of the DNS Directorate review performed by Andrew Sullivan...
      1. The definition of "Public Delegation Point" is incomplete given previous definitions of the same thing, albeit by different names. The suggestion to address this is to add something to the definition like: "Also known as public suffix, effective TLD, and public domain". It would also be good to strike the term "suffix" from the definition. More importantly, this definition does not seem to agree with the text in section 2.1. In 2.1, the draft says "Since the policy is published at the Public Delegation Point, the policy applies to all subordinate domains..." The definition of Public Delegation Point means that "com" is the delegation point ("under which DNS names are delegated": "com" does the delegation). Second, this seems to suggest that the policy flows top-down and constrains subordinate names, but that's not what's in section 3.
      2. The definition of "Resource Record" has several issues. First, it does not incorporate the fact that RRs come in sets. Given that, this definition is stretching things to the point of being misleading. A proposed fix to the definition is : "A particular entry in the DNS including the owner name, class, type, time to live, and data, as defined in [RFC1035] and [RFC2181]. Resource records come in sets identified by the owner name, class, and type. The time to live on all RRs is always the same. The data may be different among RRs in an RRset."
      3. Section 2.1 gives this example for specifying additional information:
      "$ORIGIN example.com . CAA 0 issue "ca.example.net; account=230123" "
      And the text following it states : "The syntax and semantics of such parameters is left to site policy and is outside the scope of this document."
      If the above is true, how does a consumer of this information know that the ";" is a separation character? If this document is defining the "issue" tag, shouldn't have to specify the syntax?
      4. It appears that the Extended Issuer Authorization Set notation (section 3) needs some work. The first issue is the one raised in the Gen-ART review about tree-climbing. The other is the implicit constraint that this notation puts on subordinate names. If I control a domain with a published CAA record and delegate a sub-domain to someone, they are stuck using the CA of my choice unless they publish their own CAA.
      5. Section 3 also states the following:
      "The DNS defines the CNAME and DNAME mechanisms for specifying domain name aliases. The canonical name of a DNS name is the name that results from performing all DNS alias operations. An issuer MUST perform CNAME and DNAME processing as defined in the DNS specifications [RFC1035] to resolve CAA records."
      In combination with the tree-climbing issue, this is going to be problematic. Suppose we have :
      example.net DNAME example.com
      example.net CAA [$x]
      foo.example.com CAA [$y]
      If someone requests a certificate for bar.foo.example.net, does the CAA at example.net rule, or the CAA at foo.example.com? It appears that the one at foo.example.com would be chosen because the alias resolution appears to be performed before anything else. Is that the intent?
    5. Brian Haberman: Comment [2012-07-18]:
      (ten items)
    6. Russ Housley: Discuss [2012-07-14]:
      The Gen-ART Review by Richard Barnes on 6-July-2012 started a discussion. Some points have been resolved, and others have not. Looking in the entry associated with the public delegation point as opposed to tree walking has not reached closure. When the discussion does reach closure, I believe the document should be updated to capture the agreed points from the discussion.
    7. Barry Leiba: Discuss [2012-07-18]:
      [Update: DNS Directorate review has arrived, and Brian is handling the issues from that. I'm removing that from my DISCUSS.]
      One point remaining:
      In section 6.2: "Addition of tag identifiers requires a public specification and expert review as set out in [RFC6195]"
      RFC 6195 isn't the usual reference for IANA registration policies (we usually use RFC 5226). Using another is fine if it's clear what you mean, but I don't see that it is: What section of 6195 defines the expert review policy you're talking about? The phrase "Expert Review" (capitalized, as it turns out) appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and it's quite specific to DNS RRTYPEs -- it requires posting a message with a specific template to dnsext@ietf.org, for example, and it gives guidelines to the expert (in Section 3.1.2) that don't seem to be applicable here (they're also specific to RRTYPEs).
      Please clarify what the policy is, exactly where it's documented, and what the designated expert is supposed to consider in her review.
    8. Pete Resnick: Comment [2012-07-18]:
      "label = 1* (ALPHA / DIGIT / "-" )"
      If you're trying to conform to host syntax, I wish you would reference it from another RFC. In any event, the above is not correct. Try:
      "label = (ALPHA / DIGIT) *(["-"] (ALPHA / DIGIT))"
    9. Robert Sparks: Comment [2012-07-18]:
      Should automata processing a record with the iodef property do any sort of validation of the URI it finds there before using it? (The examples point into the same domain, but that's not a restriction, right?).
      The draft says "Web Service" a few times, sometimes capitalized that way, when pointing to RFC6546. This could lead to confusion with WSDL/SOAP which RFC6546 does not use.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) (Proposed Standard)
    draft-sandlund-rfc4996bis-02
    Token: Wesley Eddy
    Discusses/comments (from ballot draft-sandlund-rfc4996bis):
    1. Stewart Bryant: Comment [2012-07-19]:
      As Sean says it would be useful to have the differences more visible at the front of the document. A forward reference in the Introduction would in my view be an acceptable way to achieve this.
    2. Stephen Farrell: Comment [2012-07-16]:
      (three items)
    3. Russ Housley: Discuss [2012-07-17]:
      The issue below is the same as the one raised in the Gen-ART Review by Joel Halpern on 16-July-2012.
      Section 5.2.2.2 on negative acknowledgments includes the following:
      "... unless it has confidence that information sent after the packet being acknowledged already provides a suitable response ..."
      This deals with a specific response to the NACK, it is unclear what constitutes confidence. Other places in this document that refer to gaining confidence provide specific descriptions of how it is gained. The primary methods for gaining confidence are receiving acks or sufficient transmissions. If all that is meant here is sufficient transmissions, please say so.
    4. Sean Turner: Comment [2012-07-17]:
      I think it would be better if the changes were nearer the front of the draft. I suggest moving s9 to s1.1 (again this is only a suggestion).

    Telechat:

  2. A User Agent Profile Data Set for Media Policy (Proposed Standard)
    draft-camarillo-rai-media-policy-dataset-02
    Token: Robert Sparks
    Note: Mary Barnes is the document shepherd
    Discusses/comments (from ballot draft-camarillo-rai-media-policy-dataset):
    1. Stephen Farrell: Discuss [2012-07-16]:
      This discuss & comment probably looks worse than it is. I'd hope it'll all be easily sorted.
      (1) 3.3.1, visibility attribute says if UA is "permitted" to show the user stuff - yuk! Shouldn't that be the UA developer's choice? I'd say s/permitted/advised/ would be fine. I think the "SHOULD NOT display" here is just inappropriate as its nothing to do with interoperability and is just silly, since people will make tools to show that stuff if you try hide it. (I realise that my suggested change conflicts with Barry's suggestion for fixing the issue in his comment, but I think the way to fix the problem we've both identified is to get rid of the pretence that you can hide stuff you send the UA.)
      (2) 4.1, Why MUST a UA include the remote-host-port in all session-info documents? That seems a bit privacy unfriendly to say the least. I can see that it might be needed sometimes, but why all the time, and why can't the UA just not tell the policy server who its calling? (Same comment about elsewhere where the same information is a MUST.)
      (3) I think section 9 (or somewhere else, I don't care) needs to call out when TLS is needed, that is, when TLS MUST be used and how. (I'm only asking about TLS since S/MIME usage here is apparently mythical.) In particular, I think you need to say when a UA MUST authenticate a policy server or source of policy information, and how it can check that its getting the right policy from the right source or giving stuff to the right server. I think sending out remote host/port information and accepting intermediary information in particular would seem to call for use of TLS with server-authentication, though there may be additional cases too. I would imagine that you'd need to check that the policy-server element (if present) matches the TLS server cert somehow. If the policy-server is absent, or when a UA is sending sensitive information, then I don't know how you'd know you're giving/getting the right policy info. Finally, do merge operations need a web-origin like concept? Without that, it'd seem like anywhere I visit might be able to corrupt my UA's "policy state" (to invent a term that might be missing.)
      Sorry to lump a few different things together in point (3); I suspect that we'll tease them apart in the discussion, but I'm not sure right now how to do that properly.
    2. Stephen Farrell: Comment [2012-07-16]:
      (14 items)
    3. Barry Leiba: Discuss [2012-07-14]:
      [Update: I neglected to take into account the new media-types procedures document we just approved. The media-type registration request has been done correctly, and IESG approval of this RFC is adequate to have IANA make the registration. My apology for this erroneous part of the DISCUSS, which point is now cleared.]
      Section 3.3.4 "The value of the 'media-type' attribute MUST be the media type, such as 'audio', 'video', 'text', or 'application'."
      It looks like this value is meant to be one of the registered top-level media types in the Media Types Registry, yes? If so, please say that. As it is, it seems underspecified: you give four examples, but I might be allowed to put "font" in there, which we've batted around as a possible new top-level media type that doesn't yet exist... I'm not sure.
      I think it's unlikely that you want to allow unregistered top-level types. Maybe this?:
      NEW: The value of the 'media-type' attribute is the media type of the stream, and MUST be a (top-level) Media Type that is registered in the Media Types IANA registry. Examples are 'audio', 'video', 'text', and 'application'.
      This also applies to the <media-type> element.
      For the <media-type-subtype> element, you say this:
      Section 6.2.1 "The <media-type-subtype> element contains a media type and subtype that identifies a codec. The value of this element MUST be a media type and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629])."
      By using the RFC4855 citation, are you really saying this?:
      NEW: The <media-type-subtype> element contains a media type and subtype that identifies a codec. The value of this element MUST be a media type and subtype that is registered as an RTP Payload Type [RFC4855], separated by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or video/H263 [RFC4629]).
      (Of course, you might want to allow for unregistered subtypes, so I'm not sure exactly what you want. What I am sure about is that the document needs to be clear about where these primarily come from, and when it's appropriate to stray.)
    4. Barry Leiba: Comment [2012-07-13]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      Section 3.3.1 "hidden: Specifies that the user agent SHOULD NOT display the property value."
      SHOULD NOT, really? If an administrator wants to hide this, she can't rely on its being hidden? Why isn't this MUST NOT? Or maybe what you want is this, to go with the subsequent sentence?:
      NEW: hidden: Specifies that the user agent MUST NOT display the property value to ordinary users.
      Other comments; no need to respond to these. Really, I'm just grumbling. (two items)
    5. Pete Resnick: Comment [2012-07-18]:
      (four items)
    6. Sean Turner: Discuss [2012-07-19]:
      Hmm so under what circumstances would I not wan the protocol used to distribute session info and session policy doucments to not ensure authentication, privacy, and message integrity?
      Is the gist of the must for shared-secret that you consider that to be the only item that MUST be kept private? Not user id too?
    7. Sean Turner: Comment [2012-07-19]:
      s3.3: Says the recipient MUST ignore the attribute. Is the recipient the user agent or the user? I suspect it's the former - shouldn't it say that instead?
      s3.3.1: Is there an override on this? I'm thinking I'm with Stephen here. An additional reason is that normally display stuff (my technical term) is out-of-scope - isn't it?
      s4.2: optional is redundant: r/MAY contain the optional/MAY contain the

    Telechat:

  3. Naming Things with Hashes (Proposed Standard)
    draft-farrell-decade-ni-09
    Token: Barry Leiba
    Note: Alexey Melnikov (Alexey.Melnikov@isode.com) is the document shepherd.
    IPR: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Larry Masinter
    IPR: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation
    Discusses/comments (from ballot draft-farrell-decade-ni):
    1. Stewart Bryant: Comment [2012-07-19]:
      Wes makes an interesting point about whether this should be experimental.
      If ever there were a good case for embedded mp4 in an RFC it is the nih example in section 8.3
    2. Wesley Eddy: Comment [2012-07-17]:
      I don't have any technical problem with this document.
      I doubt that it needs to go on the standards track though; it smells experimental to me. There are lots of potential uses, but who is using it?
      There's a note that it's similar to magnet URIs, but no mention of why it's better. Since magnet is in widespread use, this seems important to give the analysis for, otherwise we should just be putting magnet on the standards track.
    3. Adrian Farrel: Comment [2012-07-15]:
      I have no objection to the publication of this document. Here are a couple of minor thoughts you might consider before publication...
      (three items)
    4. Pete Resnick: Discuss [2012-07-19]:
      I do not think this document has a reasonable URI registration and I would like more information from the Expert Reviewer of how this passed muster. The current registration template says:
      Applications/protocols that use this URI scheme name: General applicability.
      I do not see how that satisfies the requirements of a URI registration. Moreover, I think this is indicative of a deeper problem: I cannot find an example of a URI that works the way ni: URI seems to work. The document provides no resolution mechanism for these URIs. The resolution mechanism seems to be "this will be resolved however your local implementation decides that they are to be resolved." This is not interoperable. And as far as I can tell, this is a big architectural shift from the normal use case of URIs. I think this needs pretty serious discussion.
    5. Robert Sparks: Comment [2012-07-17]:
      Consider explicitly calling out that padding (=) is not included when base64url-ing.
    6. Sean Turner: Discuss [2012-07-17]:
      In s2 you point out that sha-256-32 is useful for naming but not so much for security. When values are included in the hash algorithm registry should a column be included to indicate whether they are useful for security and naming or just naming? If not in the registry then in the document in which they are defined?
    7. Sean Turner: Comment [2012-07-17]:
      (nine items)

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements (Informational)
    draft-ietf-karp-threats-reqs-05
    Token: Stewart Bryant
    Note: Brian Weis (bew@cisco.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-karp-threats-reqs):
    1. Adrian Farrel: Comment [2012-07-19]:
      I am pleased to support the publication of this document.
      Requirement 20 in Section 4 seems to be the only one without an RFC 2119 word.
      Think this should be: "Thus proposed solutions SHOULD be evaluated carefully with"
    2. Brian Haberman: Comment [2012-07-13]:
      - Section 1.1: s/assymetric/asymmetric/
      Section 2.1: * I agree with Barry that the document should not inter-change confidentiality and privacy. They are different components and can be accomplished in vastly different ways.
      Section 2.3: * Does backwards compatibility need to be considered? Or is it being implied within the incremental deployment discussion?
      Section 4: * It may be the way I am reading them, but requirements 21 and 22 seem to be contradictory. Requirement 21 says "if you can, centralize some features to reduce the work load on all routers". On the other hand, requirement 22 says "don't build in any external dependencies".
    3. Barry Leiba: Comment [2012-07-12]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      (12 items)
    4. Sean Turner: Discuss [2012-07-19]:
      Thanks to the authors for getting the draft this far. First off a big mea cupla for following KARP and not getting to this earlier.
      Steve Kent's secdir review pointed out many issues with this draft. Many of those are in the comments section and some are here. I guess I'm willing to be shouted down that the following things turned up during the secdir aren't blocking, but I think we might be doing a disservice to others if we don't fix these because I find the draft hard to follow and some of the requirements are vague.
      1) s1.1: The KDF definition lists four sources from which to generate keys. Two seem to be the same, (i) a random or pseudorandom seed value and (iii) a non-uniform random source, I'd like to understand how they differ.
      2) s1.1: The KMP definition indicates that the KMP determines how secret keys are generated - this isn't always true. Are you presupposing a solution? Here's some suggested text:
      OLD: It determines how secret keys are generated and made available to both the parties.
      NEW: It determines how secret keys are made available to both parties and in some cases also determines how the secret keys are generated.
      3) s1.1: PRF vs KDF: The definitions look to be pretty similar. It'd be worth saying how they're different or whether they're the same. Often times PRFs are used in KDFs. Maybe Brian can help with this based on (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kdf-uses/).
      4) s2.3 Step 4: Is there an agreement about the common operator teams and common deployment process? How will this help evaluations? Who will conduct the survey? Who's going to perform the interviews? Is there a citation for the interviews?
      5) s2.3: Step 4: Having some trouble parsing the following:
      "Measurably, we would like to see an increase in the number of surveyed respondents who report deploying the updated authentication and integrity mechanisms in their networks, as well as a sharp rise in usage for the total percentage of their network's routers."
      Are you asking for more people to deploy and to fill out the surveys?
      6) s3.1.2: Stolen Keys (s3.1.2) aren't a threat source but Terminated Employees are (s3.1.2.1).
      6a) How about re-titling s3.1.2.1 to INSIDERS and moving it to s3.1.2 and moving s3.1.2 to somewhere else (not sure where yet).
      6b) RFC 4593 says there's two sources: outsiders (addressed) and byzantine (addressed). Are we updating RFC 4593 by adding a new type of adversary?
      7) s3.2: I thought a non-goal was "Message content validity (routing database validity)" so it's unclear why FALSIFICATION is in scope?
      8) s3.2: I know 4593 uses INTERFERENCE, but how are the things that are listed under that any different than the DoS attacks (or integrity violations that an attacker would try to us in a DoS attacks) introduced here? In s3.3 you list DoS under INTERFERENCE so maybe we should try to make the two sections be more alike and group them together somehow.
      9) I know 4593 uses "noise" but how's that any different than inserting messages, replying out-dated messages, corrupting messages, changing message contents? I can hear everybody saying it's in 4593 go away, but we don't have to continue to repeat the sins of our fathers/mothers.
      10) s3.2: The brute force paragraph indicates that the key should be long enough to thwart attacks 10 or more years out. That's a big range - is it 11 or 100 years? The answer is going to drive the solution.
      11) s3.2/3.3: FALSIFICATION is listed as in scope in 3.2 and out of scope in 3.3. Very confusing.
      12) s4 #3: Algorithm agility is about being able to transition from one alg to another not supporting two MTI algs at the same time. I think #3 needs to be reworded.
      13) s4 #5: Needs more detail about inter- and intra-session replay protection.
      14) s4 #7: If keys are only changed when somebody leaves it is not very periodic, confidentiality is out-of-scope, and I'm not sure what you mean by entropy (are you saying to add more entropy - i.e., bigger key). How about:
      "Intra-session re-keying which occurs without a break or interruption to the current routing session, and, if possible, without data loss, MUST be specified. Keys need to be changed periodically, for operational confidentiality (e.g. when an administrator who had access to the keys leaves an organization) and for entropy purposes, and a re-keying mechanism enables the operators to execute the change without productivity loss."
      To:
      "Security mechanisms MUST specify a means to effect intra-session re-keying without disrupting a routing session. Keys need to be changed periodically, for authentication and integrity (e.g., when an administrator who had access to the keys leaves an organization)."
      15) s4 #7 & #8: Are #7 and #8 at odds? Is there any other way to rekey an intra-session without sending the thing twice under two different keys? Maybe "intra-" should be dropped?
      16) s4 #8: "Efficient" rekeying - how do we measure this? One person's efficiency is another person's IPR ;) Maybe this just needs to be reworded:
      "Re-keying SHOULD be supported in such a way that it can occur during a session without the peer needing to use multiple keys to validate a given packet."
      17) s4 #12: Why not MUST consider and allow for future use of KMP? I guess we could define one and then chuck it away but would we really do that?
      18) s4 #13: Levies the following requirement:
      "It MUST be obvious how the keying material was obtained, and the process for obtaining the keying material MUST exist outside of the Routing Protocol."
      Obvious to some is not obvious to others. I think this needs to be restated. Is this just about a key identifier so you can locate it in the table?
      19) s4 #14: Levies a requirement of no more than 5% increase in convergence time. It then goes on to say this time will be measured by router vendors and ISPs. Are folks not in that group going to be able to verify the data too?
      20) s4 #19: In the following:
      "Proposed solutions MUST support an incremental deployment method that provides some benefit for those who participate."
      Who are those? Is that inter- or intra-AS deployments?
      21) s5: Isn't the last paragraph in the security misplaced? Ought it be in the mainbody describing what's in and what's out?
    5. Sean Turner: Comment [2012-07-19]:
      There's a whole lotto these and I'm willing to provide the authors with an update .nroff or .txt file.
      (many item: see link)

    Telechat:

  2. Use Cases for Content Delivery Network Interconnection (Informational)
    draft-ietf-cdni-use-cases-09
    Token: Martin Stiemerling
    Note: Francois Le Faucheur (flefauch@cisco.com) is the Document Shepherd.
    IPR: Azuki Systems, Inc.'s Statement about IPR related to draft-ietf-cdni-use-cases-04
    Discusses/comments (from ballot draft-ietf-cdni-use-cases):
    1. Benoit Claise: Discuss [2012-07-19]:
      I support this document, one easy-to-fix DISCUSS though Section 1.1 Terminology
      "We adopt the terminology described in [I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-framework]."
      We need to read the terminology from [I-D.ietf-cdni-problem-statement] in order to understand this draft. So this should be a normative reference, right? Note: this is fine since the cdni-problem-statement is now in the RFC-editor queue.
      However, wrt [I-D.ietf-cdni-framework], I don't think it's fine to have an informative reference (regarding terminology) to a future document. What if the definitions change after this document publication, will this document still be readable? Maybe yes, maybe no. The good news is that the 7 terms defined in [I-D.ietf-cdni-framework] are not used in this document. So you should simply remove "and [I-D.ietf-cdni-framework]"
    2. Benoit Claise: Comment [2012-07-19]:
      - Title says "1.3. Rationale for Multi-CDN Systems" but the content is about CDN Interconnection. Shouldn't the title be "Rationale for CDN Interconnection"? Or maybe I missed a subtle difference between the two terms?
      - I like the fact the terms defined in [I-D.ietf-cdni-problem-statement] are capitalized. It would be nice to clearly mention that in the terminology section. It helps a lot the reader as he doesn't know what he doesn't know (i.e. that a term is defined somewhere else.). Yes sure, you wrote "We adopt the terminology described in [I-D.ietf-cdni-problem-statement]" that would help the reader anyway.
      Example: rfc5982: "The IPFIX-specific and PSAMP-specific terminology used in this document is defined in [RFC5101] and [RFC5476], respectively. In this document, as in [RFC5101] and [RFC5476], the first letter of each IPFIX-specific and PSAMP-specific term is capitalized along with the IPFIX Mediation-specific terms defined here."
      Note: I haven't checked the consistency of the capitalization
      - " The End User benefits from this arrangement through a better Quality of Experience (QoE), "
      QoE definition in RFC6390
    3. Adrian Farrel: Comment [2012-07-19]:
      Was nothing learnt from RFC 3570 and no mention or acknowledgement of the authors of that work due?
      Would it be possible to add a figure to Section 3? They are very helpful in 1.3 and 2.4.
      Section 8 could point to A.2
    4. Stephen Farrell: Discuss [2012-07-16]:
      I am concerned that this document is fairly full of DRM related use cases, when DRM mechanisms are explicitly ruled out of scope by the WG charter.
      - The "distribution rights" example in 1.3 is basically a DRM thing.
      - The last paragraph of 2.4 (referring to A.1) is also a DRM example.
      - The second paragraph of 3.1 talks about "exclusive distriubtion rights."
      - A.1 refers explicitly to "license violations."
      - A.2 refers to "content protection"
      - It seems therefore that section 5 is thus not justified with the current DRM-only examples.
      Are there no better (technical) reasons why policy needs to be applied that could be used as examples? Note: I'm not saying these examples are "wrong" but rather that we need non-DRM use-cases to motivate things.
    5. Stephen Farrell: Comment [2012-07-16]:
      - I don't get how End-user B in 2.4, who's not allowed access stuff, is relevant for CDNI. Are you saying that CNDI protocols will carry authentication or authorization PDUs specific to end-users? I didn't think that was going to be the case.
      - Another patent declaration on a use-cases document. Sigh. (No action is required, I'm just lamenting;-)
    6. Russ Housley: Comment [2012-07-17]:
      Please consider the editorial comment from the Gen-ART Review by Suresh Krishnan on 16-July-2012.
    7. Barry Leiba: Comment [2012-07-10]:
      Totally trivial:
      Abbreviations: WiFi: Wireless Fidelity
      Really? You made that up, right? I suggest this: WiFi: Wireless local area network (WLAN) based on IEEE 802.11. (Or just the first part.)
    8. Sean Turner: Comment [2012-07-18]:
      0) Process Question: Do you want to also make RFC 3570 historic?
      1) Stephen beat me to the DRM issue - needless to say I agree with him.
      2) s1.2: DRM is listed but not used in the draft. Use it or lose it :)
      3) a/s1/s1.3/s2.1: Anytime I see "cost" I think marketing. Honestly think you could elide the cost discussion from the draft and it would be fine. Besides cost savings are already called out in the problem statement. (reminder this is a non-blocking comment).

    Telechat:

  3. Ericsson TWAMP Value-Added Octets (Informational)
    draft-ietf-ippm-twamp-value-added-octets-04
    Token: Wesley Eddy
    Note: Henk Uijterwaal (henk@uijterwaal.nl) is the document shepherd.
    IPR: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ippm-twamp-value-added-octets-03
    Discusses/comments (from ballot draft-ietf-ippm-twamp-value-added-octets):
    1. Stewart Bryant: Discuss [2012-07-16]:
      I am concerned that there is no provision in the protocol to identify the vendor who has defined the extension. Thus if one equipment is deploying this extension, and it's peer is from another vendor, there appears to be no way for the two equipments to resolve the semantics of the extension that each may be attempting to use.
      The best approach in these circumstances would seem to be to publish an update to RFC5357 providing a well defined vendor extension mechanism including a vendor identifier, and then to carry this added value information behind the vendor identifier.
    2. Benoit Claise: Discuss [2012-07-18]:
      - The last part of the paragraph concerns me:
      "This memo contains the description of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics."
      So basically, you want to document a prototype, for which the IETF community is currently working on problem statement? What do I miss?
      - The way I understand the two following paragraphs ...
      "The definition of a structure for embedding a sequence of value-added fields at the beginning of the Packet Padding field [RFC5357] or Packet Padding (to be reflected) field [RFC6038] in the TWAMP test packets and, ..."
      "This memo assumes the TWAMP responder is configured through non-standard means to interpret the value-added padding octets embedded in each TWAMP test packet."
      ... is that you want to document a cover channel. I mean, the semantic of what you include is completely unknown as far as I can tell. Again, what do I miss?
      - I support Stewart's and Robert's DISCUSS
      - Regarding the following sentence ...
      "Assignment of a proprietary TWAMP mode communicated during TWAMP control connection setup"
      ... I don't see any reference to proprietary TWAMP mode in RFC5357. Practically, how is it done?
      I'm wondering if you should not specify an "experimental" mode, and specify this document as using this "experimental" mode, avoiding any potential clash.
      The following two sentences seem contradictory to me
      "This memo does not extend the standard modes of operation through assignment of a new value in the Modes field (see Section 3.1 of [RFC4656] for the format of the Server Greeting message). A new mode is recommended to communicate feature capability during control connection setup."
    3. Adrian Farrel: Discuss [2012-07-19]:
      The "Document Quality" section of the ballot write-up seems to be missing (it just shows the questions).
      I would like to discuss this point with the rest of the IESG during the telechat before updating my ballot.
      Notwithstanding the working group's non-objection to the publication of this document, it seems like an end-run on the working group process. As I understanding it, the working group has agreed that there is a problem to be described and resolved inthis area, but has not agreed that this is the right problem or the right solution. Doesn't publication of this document encourage adoption of this specific solution without agreement from the WG?
      For example, the text says: "The purpose of this memo is to describe the Ericsson TWAMP Valued-Added Octets feature (version 1) for TWAMP [RFC5357]."
      But that hides the real puprpose. Why is there a need to describe the feature in an RFC?
      I would also like to understand better the way in which this document relates to existing and future standard implementations. The text states:
      "This memo assumes the TWAMP responder is configured through non-standard means to interpret the value-added padding octets embedded in each TWAMP test packet."
      This assumption is fine as far as it goes, but you need to document what happens when there is a mismatch of configuration. How will a legacy node react if it receives this form of overloading? How will an Ericsson node react if it receives normal padding? What will happen if a future standards track document uses the padding in a different way?
      Furthermore, this document seems to specify a crass overloading of fields when it would be more appropriate to define a correct protocol extension. Such overloading often leads to interoperability issues with implementations that do strict checking or with future extensions that assign previously reserved bits for specific uses.
      As 5357 states... "Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be generated independently of any other pseudo-random numbers mentioned in this document). However, implementations MUST provide a configuration parameter, an option, or a different means of making Packet Padding consist of all zeros. Packet Padding MUST NOT be covered by the HMAC and MUST NOT be encrypted."
      Given this, I don't see how backward compatiblity can be achieved or how the Ericsson extensions can be secured.
    4. Russ Housley: Comment [2012-07-15]:
      Please consider the editorial comment from the Gen-ART Review by Peter Yee on 28-June-2012.
    5. Robert Sparks: Discuss [2012-07-18]:
      The document encourages proprietary use (essentially, squatting) in a space reserved for expanding the protocol. In general that's proven to be a problem for other protocols. Can the document say why this one is different? Since an out of band agreement would need to be made before using a proprietary mode value, why use it at all instead of just relying on configuration of each end?

    Telechat:

  4. An IETF URN Sub-Namespace for OAuth (Informational)
    draft-ietf-oauth-urn-sub-ns-06
    Token: Stephen Farrell
    Note: Derek Atkins (derek@ihtfp.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-oauth-urn-sub-ns):
    1. Russ Housley: Comment [2012-07-15]:
      Please consider the editorial comment from the Gen-ART Review by Ben Campbell on 3-July-2012.
    2. Sean Turner: Comment [2012-07-16]:
      Consider Tero Kivinen's suggestion to add a similar note than what is in RFC2141 because adding pointer to another document which says "there is nothing here", isn't that helpful.

    Telechat:

  5. A Framework for DNSSEC Policies and DNSSEC Practice Statements (Informational)
    draft-ietf-dnsop-dnssec-dps-framework-08
    Token: Ronald Bonica
    Note: Stephen Morris (sa.morris7@googlemail.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-dnsop-dnssec-dps-framework):
    1. Stephen Farrell: Comment [2012-07-17]:
      - 1.1: Is this really for "users" to evaluate the strength of DNSSEC? I don't know any users who'd do that. Maybe admins of some sort.
      - PKI definition: I'd love if you deleted non-repudiation since a PKI, and DNSSEC in particular, doesn't get you that. (By itself.)
    2. Russ Housley: Discuss [2012-07-18]:
      It seems that a DNSSEC signer can start out under one set of policy documents, and then for whatever reason the policy changes and the DNSSEC signer starts using a revised policy. In this situation, the parties validating the signature have no means to determine that the signer is following a different policy. Please explain the value of the policy to the parties that rely on these signatures. At a minimum this possibility needs to be explained in the Security Considerations.
    3. Russ Housley: Comment [2012-07-18]:
      These comments come from a discussion with one of the authors of RFC 3647:
      DNSSEC Policy definition seems off target to me. Are these all of the requirements or just the security requirements?
      The definition of PKI is not wrong, but it misses an important element that is important in the DNSSEC context too. That is, the system depends on trusted distribution of public keys.
      The definition of Signing Key is incomplete. The private key is used to sign. The corresponding public key is used to validate the signature. This is especially important when this definition is used in conjunction with the definition of Trust Anchor. A Trust Anchor only includes the public key. One way to resolve this is to define Key Pair or Asymmetric Key Pair.
      I think that Page 7 and 8 could be more clear. A DP is a statement of security requirements (not principles). The DP is best used to communicate requirements that must be met by complying parties; as such it may also be used to determine or establish equivalency between policies associated with different DNS zones. A DPS describes the actual controls employed to meet the requirements of applicable DP.
      In Section 4.4.2, please consider the addition of a crypto officer that controls the private keys. Also, which of the listed admin roles is responsible for the DNS and the network?
      In Section 4.4.4, please consider other records that may need to be kept for a period of time, such as records of key roll over, the personnel assigned to various roles, child zone manager verification, and so on.
      On Page 18, two person control is a special case of n out of m, where n = 2 and m is >= 2.
      In Section 4.5.2, please consider moving items 3 and 5 to another section. The points are not about the signing environment; they are about the recovery of the signing private key after a failure of some sort.
      These comments are a portion of the Gen-ART Review by Peter Yee:
      Section 4.4.5 discusses how to handle key compromise. It might be useful to discuss here or somewhere else in the document how the compromise is prevented from recurring if there were no attenuating measures in place beforehand. That might well lead to a revision of the DP or DPS. The draft doesn't really discuss under what circumstances a document should be iterated or amended.
    4. Barry Leiba: Discuss [2012-07-19]:
      From the shepherd writeup: "There was a concern about a possible copyright issue, but only in respect to a pre-RFC5378 RFC. Parts of RFC 3647 have been used in the draft, so the authors have contacted the authors of RFC 3647 requesting permission to use text from it. All who have replied (four out of five) have given that permission."
      The document doesn't have the pre-5378 boilerplate and, unless the fifth 3647 author replies, it needs it. This DISCUSS is a reminder to make that change.
    5. Sean Turner: Discuss [2012-07-19]:
      Having written a couple of CPs and CPSs (and depending on how you look at it that's either ;) or :( )
      1) Is it purely political that you're including the following "There are no agreements with the relying parties."
      Is the "yet" coming once a DPS is written? It can be pretty easily argued that publishing a DPS is a form of agreement. Those that use the signatures are relying on them to do x and y but not z. Or are you simply trying to telling people to not write RP agreements?
      2) So I hope I'm not stepping in it here, but there's a couple of places where the draft discusses TA distribution. Isn't that already addressed with adequate documentation - and can't you just point to that? I.e.: https://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt.
      Further, I thought the goal of DNSSEC was to encourage IANA as *the* TA. Some of the wording seems to not entirely support that. Was this done purposely?
      3) This ought to be easy to clear up but I wanted to check on this:
      s4.6.1: Are the changes to the algorithms performed according to IETF process? Should this section explicitly call that out?
    6. Sean Turner: Comment [2012-07-19]:
      This so short for a policy document! :) I also saw that Russ had a lengthy set of comments, and I apologize for not having time to skim through them and look for duplicates. These are primarily based on a review by Steve Kent.
      (many items)

    Telechat:

  6. Distribution of diverse BGP paths. (Informational)
    draft-ietf-grow-diverse-bgp-path-dist-07
    Token: Ronald Bonica
    Note: Peter Schoenmaker (pds@lugs.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-grow-diverse-bgp-path-dist):
    1. Stewart Bryant: Comment [2012-07-18]:
      This document has abbreviations that do not seem to have been expanded on first use: AS, P (in the Figs), RR'
      "For a given destination "D" ASBR1 and ASBR2 will each have an external path P1 and P2 respectively." is an assumption not a statement as far as I can see.
    2. Benoit Claise: Discuss [2012-07-18]:
      - "The need to disseminate more paths than just the best path is primarily driven by three requirements. First is the problem of BGP oscillations [I-D.ietf-idr-route-oscillation]."
      Searching for ietf-idr-route-oscillation, I realized that this is now RFC3345, published in 2002 !!! Have you run the idnits on this draft? This error is obviously flagged, but there are a couple of extra ones:
      == Unused Reference: 'RFC2119' is defined on line 843, but no explicit reference was found in the text
      == Unused Reference: 'RFC5226' is defined on line 853, but no explicit reference was found in the text
      == Unused Reference: 'RFC4984' is defined on line 898, but no explicit reference was found in the text
      - "This is achieved by including as a part of the NLRI an additional four octet value called the Path Identifier."
      It took me a while to understand that you actually refer to draft-ietf-idr-add-paths-07 in the section 2.1 Very confusing, since I read, in sequence:
      "This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. The only upgrade required is the new functionality on the new or current route reflectors."
      ... "This is achieved by including as a part of the NLRI an additional four octet value called the Path Identifier."
      Please be explicit.
      - The relationship with draft-ietf-idr-add-paths-07 is unclear to me. If we have draft-ietf-idr-add-paths-07, do we still need this solution? My conclusion from the section 2 is no! It's only after reading through section 3 that I finally understood: your propose "The diverse BGP path dissemination proposal" as an alternate solution to draft-ietf-idr-add-paths-07, right? Your draft title and abstract are very misleading. First paragraph says: As defined and widely deployed today BGP has no mechanisms to distribute alternate paths Second paragraph: This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes.
      Alternate to what? Now, I understand that it's alternate to draft-ietf-idr-add-paths-07 Please rewrite the abstract. Somehow it should extract information from the section 3 and from one of paragraphs in section 2.1:
      "While it needs to be clearly acknowledged that the add-path mechanism provides the most general way to address the problem of distributing many paths between BGP speakers, this document provides a much easier to deploy solution that requires no modification to the BGP protocol where only a few additional paths may be required. The alternative method presented is capable of addressing critical service provider requirements for disseminating more than a single path across an AS with a significantly lower deployment cost"
      And clearly mention the name of your proposal "The diverse BGP path dissemination proposal", which I see from time to time in the draft. Btw, should this be the document title?
    3. Benoit Claise: Comment [2012-07-18]:
      - OLD: The BGP protocol as defined today has no mechanism to distribute other then best path between its speakers.
      NEW: The BGP protocol as defined today has no mechanism to distribute other than best path between its speakers.
      - add an extra "," in the following section
      "As it has been proven that distribution of only the best path of a route is not sufficient to meet the needs of continuously growing number of services carried over BGP, the add-paths proposal was submitted in 2002 to enable BGP to distribute more then one path."
      Btw, you mean http://tools.ietf.org/html/rfc3345 (which was done in 2002) in this case, why not clearly mention it?
      - Next paragraph mentions: "The implication of this change on a BGP implementation is that it must now maintain per path, instead of per prefix, peer advertisement state to track which of the peers each path was advertised to. This new requirement has its own memory and processing cost. Suffice to say that it took over 9 years for some commercial BGP implementation to support the new add-path behaviour in production code, in major part due to this resource overhead."
      Here, the last sentence speaks about http://tools.ietf.org/html/draft-ietf-idr-add-paths-07? If yes, why not clearly mention it
      Same remark for: "The add paths protocol extensions have to be implemented by all the routers within an AS in order for the system to work correctly."
      - "The required code modifications include enhancements such as the Fast Connectivity Restoration Using BGP Add-path [I-D.pmohapat-idr-fast-conn-restore]."
      IS this right? Isn't it?
      "The required code modifications can offer the foundation for enhancements such as the Fast Connectivity Restoration Using BGP Add-path [I-D.pmohapat-idr-fast-conn-restore]."
      - 4. Multi plane route reflection: "The idea contained in the proposal assumes the use of route reflection within the network. Other techniques as described in the following sections already provide means for distribution of alternate paths today."
      The last sentence seems to come out of the blue. At least, I don't understand why it's there.
      - Section 7
      OLD: 2. No requirement for upgrades to edge and core routers. Backward compatible with the existing BGP deployments.
      NEW: 2. No requirement for upgrades to edge and core routers (as required in draft-ietf-idr-add-paths-07). Backward compatible with the existing BGP deployments.
    4. Adrian Farrel: Discuss [2012-07-19]:
      Section 3 says many of the right things, yet it is still appears to be the case that this document does compete (intention or not) with add-paths. Would you consider strengthening the text by adding something to the effect of...
      "Provides an interim solution until the standardisation and implementation of add-paths, and until support for that function can be deployed across the network."
      Section 4: "Diverse path route reflectors need the new ability to calculate and propagate the Nth best path instead of the overall best path. An implementation is encouraged to enable this new functionality on a per neighbor basis."
      I would like to be clear on this. As phrased "Nth best path" implies there is an ordering. "Propagate" implies that that ordering is also distributed along with the path itself.
      Preserving ordering over BGP routes is not so easy (blame the MED path attribute) so I wondered:
      - Is ordering needed or do you just need the N best paths?
      - If ordering is needed, how do you ensure it is propagated?
      This also makes me wonder whether in a multi-vendor environment there is a need for all participating routers to have the same understanding of "best". If that is the case, isn't this a document that changes on-wire behavior (viz. which paths are advertised) and needs conformance in order to make a coherent deployment? That would make it standards track (see also my comment on RFC 2119).
      I can't find a description of what happens when the primary route is withdrawn. Is there a risk that this will trigger a cascade across the planes? Suppose you have two planes. Plane 1 advertises the primary route, Plane 2, secondary. When the primary route for some destination goes unreachable (say, because its next-hop disappears from the IGP) both the Plane 1 and Plane 2 RRs come to know about it roughly at the same time, though Plane 2 may actually hear first for whatever reason. Plane 1 will advance the backup route to primary and advertise it. Plane 2 will advance the route to primary, decide there is no backup any more for it to advertise, and withdraw its route. The problem is if Plane 2 acts first and withdraws the (formerly-) backup route before Plane 1 advertises it. Could this be addressed by building in a N*K delay into Plane N routers? This doesn't seem to be addressed in the I-D, and it probably should be.
    5. Adrian Farrel: Comment [2012-07-19]:
      Section 4.3: "That will allow to distribute more then single best BGP path from a given route server to such IX peer."
      s/then/than the/
      Please expand IX on first use
      I assume that RFC 2119 language has not been used because this document does not define any new protocol procedures (merely config/deployment options). I am not sure whether that is the best approach since there are some key behaviors that you want implementations/deployments to adhere to in order for the behavior you are describing.
      If you decide to continue to not use RFC 2119 language, then you should remove the reference.
    6. Stephen Farrell: Comment [2012-07-18]:
      I agree with Hilarie Orman's secdir review both about the difficulty of reading this and the possible security issues and would encourage the authors to consider the points she raised.
    7. Brian Haberman: Comment [2012-07-19]:
      I support both Adrian's and Benoit's DISCUSS points.
      This document was much harder to read than it had to be. As was pointed out by Hilarie and other, there are sections of the draft that are hard to parse until they are read 2 or 3 times. I think the document would benefit from an end-to-end grammatical review.

    Telechat:

  7. Issues with Private IP Addressing in the Internet (Informational)
    draft-ietf-grow-private-ip-sp-cores-05
    Token: Ronald Bonica
    Note: The document shepherd is Chris Morrow (christopher.morrow@gmail.com).
    Discusses/comments (from ballot draft-ietf-grow-private-ip-sp-cores):
    1. Benoit Claise: Comment [2012-07-13]:
      When I read in the abstract RFC1918 + loopbacks, I was immediately thinking: that's bad from a opeational/management point of view, because, in many networks, the loopback IP address is the unique router identifier in the NMS applications. Thinking some more... as long as the loopback addresses are unique, this should be fine. However, applying RFC1918 IP addresses to loopbacks is still looking for problem from an operational point of view. - Let's assume, in this world of acquisitions, that the network operator has to merge two networks, each using the same same private IP block for their respective loopbacks... he has to renumber one of the two networks. - Let's assume, in this connected world, that the network operator has to compare NetFlow/IPFIX flow records from different routers in different networks and those networks use the same private IP addresses block for their respective loopbacks... He has a problem, because, most of the time, the unique id in the collector is the source IP address of the UDP export, so the loopback. Same thing for syslog btw.
      I'm wondering if it would not be worth completing the section 9 "Operational and Troubleshooting issues"?
    2. Adrian Farrel: Comment [2012-07-18]:
      I have no objection to the publication of this document.
      It did feel to me,on reading the doument, that the problems reported are all associated with attempting to deploy a flat network using private addressing. However, the observation that one motivting factor is "core hiding" makes it reasonable to observe that the problems do not exist if proper network layereing is applied. Of course, such layering makes network operation more complex and also makes some functions (like traceroute) impossible or secret, while other functions (such as PMTUD) require cross-layer coordination.
      That doesn't detract from the document, but suggest that issues may be less black/white.
      OTOH one might note that IPv6 removes the largest "need" for private addressing and so this document should be reporting an interesting quirk of history!
    3. Brian Haberman: Discuss [2012-07-16]:
      These issues should be relatively easy to address, but please feel free to discuss them with me if you have a different point of view.
      1. I don't understand why Section 4 is limiting Path MTU Discovery to TCP use cases. The referenced RFCs are applicable to other transport protocols as well. I would suggest dropping any references to TCP in that section and have it focus on the general issues that PMTUD could/would encounter in the scenarios described.
      2. Section 5 makes the statement: "Scarcity of public IPv4 addresses, and the transition to IPv6, is forcing many service providers to make use of NAT." I don't believe that the transition to IPv6 is forcing ISPs to deploy NATs. I would suggest deleting that clause.
      3. I was surprised to read in Section 7 that it is *uncommon* for peering relationships to be anchored on loopback addresses. I have been told several times that this technique is quite common and allows for peering sessions to survive link/interface outages. Is there a pointer/reference that can be added that supports this assertion?
    4. Brian Haberman: Comment [2012-07-16]:
      1. The document uses several acronyms without expansion. For example, the introduction does not expand RIR on its first use.
      2. The note in the introduction could be clarified. I don't think "stolen" is appropriate in this context. The draft actually uses the correct term "squat", but only as an alternative. I would suggest removing the use of "stolen" and replacing it with "squat" since addresses are not property.
      3. The figures, especially the one in Section 3, are hard to follow. Would it be possible to re-work them with more/better delineation between devices? I can provide an example if it would help.
    5. Russ Housley: Comment [2012-07-18]:
      Please consider the suggested changes from the Gen-ART Review by Suresh Krishnan on 16-July-2012.
    6. Barry Leiba: Discuss [2012-07-18]:
      This is a very straightforward, simple DISCUSS for an IANA issue. In Section 5, the following text makes it look like a request is being made of IANA:
      "To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] requests a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space."
      IANA suggests that it be changed to this, and I agree that it needs to change to make it clear that this allocation already exists, and is not a new request:
      "To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] allocated a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10."
    7. Martin Stiemerling: Comment [2012-07-18]:
      I support Brian's DISCUSS point no. 1 about why only TCP is named for PMTUD in Section 4.
      Another point to be considered:
      Section 5., paragraph 1: "Private addressing is legitimately used within many enterprise, corporate or government networks for internal network addressing. When users on the inside of the network require Internet access, they will typically connect through a perimeter router, firewall, or network proxy, that provides Network Address Translation (NAT) or Network Address Port Translation (NAPT) services to a public interface."
      Why not simply saying that this type of traffic passes through a NAT when heading for the public Internet. It does not matter if the NAT is implemented on a stand-alone device, a router, a set top box, etc. The current text might just cause confusion for an average reader.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Cisco Systems Export of Application Information in IPFIX (Informational)
    draft-claise-export-application-info-in-ipfix-09
    Token: Ronald Bonica
    Note: Individual Submission, AD-sponsored, Nevil Brownlee is the document shepherd,
    Discusses/comments (from ballot draft-claise-export-application-info-in-ipfix):
    1. Stewart Bryant: Comment [2012-07-17]:
      Thank you for addressing my concerns
    2. Wesley Eddy: Comment [2012-07-18]:
      As with similar "Company X's FooBar" documents, I think it is bizarre to let the boilerplate say that the IETF has consensus that this is what Cisco does.
      Though I am opposed to IETF work on DPI and supporting technologies like this as they are clearly hopeless and fundamentally harmful to the Internet, I have no technical arguments with this document and no objection to publishing what Cisco is doing in this regard.
    3. Adrian Farrel: Comment [2012-07-19]:
      To the AD: Could you update the ballot and approval notes to reflect the new name of the document, please.
      To the Authors / ISE: The first section could really do with having text that explains (per the title and Abstract - but in a little more detail) that this is a Cisco-proprietary extension to IPFIX.
      I found a very skimpy sentence in Section 2 (which made me recall that I like it when the first section of a document is the Introduction :-)
    4. Stephen Farrell: Comment [2012-05-21]:
      - The reference to http://www.cisco.com/ seems wonderfully vague, but unfortunately useless. What are the "Cisco systems assigned numbers"? (I agree with this bit of Stewart's discuss)
      - 2.1: I don't think I buy the congestion control use case. (While I don't like the security use case, I do agree others might like it.)
      - 4.1: is this encouraging folks to guess what IANA might allocate for IANA to act? Seems like a bad idea.
      - 4.2: PANA-L* - I don't get how this works. How can you assign selector lengths for the PANA-L* in 4.2?
      - section 7: I don't get how some ElementId's are assigned here already but are marked as reserved in the IANA registry.
      - AppA: How is section 7 of an informative document normative?
    5. Russ Housley: Discuss [2012-07-15]:
      In response to the Gen-ART Review by Roni Even the authors created Appendix C, which references [CISCO-APPLICATION-REGISTRY]. We have been waiting for the referenced web page to appear since 29 May 2012. I do not think that the IESG should approve the document to a web page that cannot be reviewed. Please remove Appendix C and the reference.
    6. Barry Leiba: Comment [2012-07-19]:
      I agree with the comments that the boilerplate for this sort of document is odd. I think we need to look at the choices we have for what to say at the beginnings of documents, and make sure there's a good, standard option for "this is not a consensus document; we're just putting it out for information." Or maybe this says that this should have gone through the ISE.
      In any case, I have no objection to publishing this, so here we go.
    7. Robert Sparks: Discuss [2012-07-18]:
      (Hoping this is easy to clear). The header/boilerplate seems to be what would happen normally following RFC5741. What's the EDITOR NOTES: block there for? Are there clear instructions to remove it somewhere?
    8. Martin Stiemerling: Discuss [2012-07-19]:
      Sorry for this late discuss but what about user privacy? (I'm not a security AD, but I wonder anyhow)
      The document says: "Today service providers and network administrators are looking for visibility into the packet content rather than just the packet header."
      When talking about packet content and identifying applications used, we are already at the door sill to see what individuals are doing in the network.
      I've read the Security Considerations to see if the privacy aspects are being disucssed there and was very much disappointed. Especially also that the reference RFC 5101 is also not discussing user privacy.
    9. Martin Stiemerling: Comment [2012-07-19]:
      I am also wondering about the boiler plate, such as Wes does. Why is this presenting IETF consensus if it is a company's protocol only?

    Telechat:

  2. Tunneling of SMTP Message Transfer Priorities (Experimental)
    draft-melnikov-smtp-priority-tunneling-03
    Token: Pete Resnick
    Discusses/comments (from ballot draft-melnikov-smtp-priority-tunneling):
    1. Adrian Farrel: Comment [2012-07-18]:
      I have no objection to the publication of this document, and welcome that it is Experimental.
      As with many Experimental documents I review, I would like the Abstract to note the Experimental status (as, for example, is done in the first line of the Introduction). I should also like to see a little more scoping of the Experiment: - why it is experimental - what nodes participate in the experiment - how the experiment is constrained - how the experiment will be judged
      It is not mandatory to add such text (hence this is not a Discuss), but I think it really helps people work out how to work with the document.
    2. Stephen Farrell: Comment [2012-07-16]:
      - Section 7, 1st para: How would one use S/MIME to sign the MT-Priority header field? You'd have to encapsulate the message wouldn't you? I think you could omit mention of S/MIME here.
      - Section 7, 1st para (again:-): DKIM doesn't allow you to know who put this header on, just who signed it (if its included in the signature). So I think what you want to say is something like "DKIM signing allows a recipient to verify that the specified priority value was present when the message was signed, and to verify who signed the message." But the signer might not be the one that "generated" the header.
      - Same section: Calling for an MUA to use DKIM is a bit of a stretch, but would I guess work, though the key mgmt isn't very well-defined for that use-case really since you end up with per-user keys in the DNS, or have to share private keys.
    3. Russ Housley: Discuss [2012-07-18]:
      Based on the discussion following the posting of the Gen-ART Review by Martin Thomson on 8-June-2012, it seems that there is an inconsistency that needs to be resolved:
      "But now that I am looking at the two sections ("Security Considerations" and "Relay of messages to non-conforming SMTP servers"), they might be out of sync as far as requirements are concerned. So I need to tweak one or both of them to match."
    4. Barry Leiba: Comment [2012-07-09]:
      As I noted in the shepherd writeup, I have some concern about the broader applicability of this as a standard, given the trade-offs the proponents have made. That said, some of them had to be made, and there is value in implementing features from proprietary email systems in standardized ways on the open Internet. There does seem to be consensus that it's worth trying this out, and that it's not terribly unsafe to do so.
      The tunneling of the PRIORITY value through non-conforming MTAs by turning it into a message header field (MT-Priority) and then back again is a problematic technique, but is an important capability for those who need and intend to implement the smtp-priority extension. It creates a trust issue, wherein a message containing MT-Priority could be originated with a Message Submission Agent that does not know about this extension, and when the message hits a Message Transfer Agent that does support this, the header field will be turned back into a valid PRIORITY value, on the unwarranted assumption that it was authorized. Intermediate MTAs have no way to distinguish this situation from one where the field was tunneled legitimately.
      The counter-argument is that the use case for this specification involves out-of-band trust relationships, and that such situations will be known and dealt with. Only by experimenting with it will we see how (or if) it can extend to other use cases where such trust relationships aren't as clean.
    5. Pete Resnick: Discuss [2012-07-19]:
      Between Adrian's comment and Barry's, I am no longer convinced that Experimental is the correct status for this document (and I kick myself for not noticing this earlier on my own). I'm considering Informational. I'd like to discuss this issue, and not only with myself.

    Telechat:

  3. Requirements for IETF Nominations Committee tools (Informational)
    draft-krishnan-nomcom-tools-01
    Token: Russ Housley
    Discusses/comments (from ballot draft-krishnan-nomcom-tools):
    1. Stewart Bryant: Discuss [2012-07-16]:
      This is basically a sound document, but there are some details that need attention. Once these are addressed I will be happy to vote yes.
      Sec-001 and Sec-005 look the same
      "This information can only be accessed by the members of the Nomcom."
      Does the above mean voting members, voting members + chair.....?
      "AD-004: The tool MUST allow to view a list of all nominees along with their accepance or decline status."
      Must allow who?
      "AD-005: The tool MUST allow the reporting of accepance or decline status both per nominee as well as per open position."
      Reporting to who?
      "The nominees fill in a questionnaire for each of the positions for which they accept a nomination."
      .. and does what with it? Sends an email, posts it on the web site completes it on the web site?
      "FB-005: All email received on the Nomcom mailing list MUST be archived."
      For what period, and who has access to the archive?
    2. Stewart Bryant: Comment [2012-07-16]:
      "AUTH-003: The tool MUST allow the secretariat to input an email address to be provided the Nomcom chair role and a list of email addresses to be provided the Nomcom member role."
      The above requirement does not read correctly - possibly missing some "by"s
      "The filled in questionnaires are received as emails to the Nomcom mailing list."
      Surely they are sent as emails
    3. Benoit Claise: Comment [2012-07-17]:
      I support this document. However, I have some comments.
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      - When I read: "The users of the tools may have different privileges based on their role. The tool needs to support at least three levels of access:Community member, Nomcom member, Nomcom chair."
      I don't understand the "may". If you create different levels, isn't because the different levels "must" have different privileges? From there, I was wondering: what are the different privileges based on the role? I was hoping to find a definition of Nomcom member and/or Nomcom chair in one of the nomcom RFCs (RFC3777, RFC5078, RFC5633, RFC5680), along with their role definition. However, it doesn't seem to exist. Disclaimer: I have not seen https://www.ietf.org/group/nomcom/2011/private/, so it's difficult to understand if we miss requirements about the role versus privileges, or if this falls into the META-001 requirement.
      - "The tool needs to support at least three levels of access:Community member, Nomcom member, Nomcom chair.
      ... o AUTH-003: The tool MUST allow the secretariat to input an email address to be provided the Nomcom chair role and a list of email addresses to be provided the Nomcom member role."
      So which of the three levels has the Secretariat? Nomcom member? Or do you need a fourth role just for Secretariat/Tools admin?
      Along the same lines:
      "o SEC-005: The data accumulated by the tool MUST be stored in a fashion that prevents accidental exposure of the data to people who administer the server(s) on which the data is stored."
      Do you consider the Secretariat part of the "people who administer the server(s)"? I guess not. So how many roles do you need at the end?
      Editorial comments
      - OLD: QR-005: Like all other correspondance on the Nomcom mailing list, the questionnaires MUST be encrypted by the Nomcom public key before being stored.
      NEW: QR-005: Like all other correspondance on the Nomcom mailing list, the filled in questionnaires MUST be encrypted by the Nomcom public key before being stored.
    4. Ralph Droms: Discuss [2012-07-17]:
      I see some of these issues have been noted by other ADs.
      1. (cleared)
      2. What is the difference between requirements SEC-000 and SEC-005; what is the "data accumulated by the tool"?
      3. FB-001 needs to have a requirement for annoymous feedback, and for tracking the submitter of non-anonymous feedback.
      4. In FB-006, should that read "copy" rather than "move"?
    5. Ralph Droms: Comment [2012-07-17]:
      (seven items)
    6. Adrian Farrel: Comment [2012-07-19]:
      I think it is important to hurry this document through if we are serious about developing tools to make the work of NomCom less arduous. But I also think it is important to get the specification right so that the tools developed do what is required wasting neither time nor effort. In view of this, I support a number of the existing Discusses that focus on the precision of the requirements.
      We should try to learn from the tools database issues that arose in NomCom 2011. How can we ensure that the feedback that has been entered remains available to the NomCom and does not have to be reconstructed or retrieved by special action?
      Section 8
      IIRC the current tools do not allow an individual to revist the feedback that they have already entered for a candidate. Although it is possible to request an email copy of the feedback at the time it is entered, it is not possible to recall the feedback through the web page. Such a feature would be useful as a reminder before an interview, for correlation of feedback against multiple candidates, and to allow updates to feedback as new thoughts arise.
      It would be nice to add this feature.
    7. Stephen Farrell: Comment [2012-07-16]:
      - General question and a near-discuss: What, if anything, should happen to the stored/archived information after the nomcom has done its work? And if something should happen, (e.g. deletion) when ought that happen? This may all be in some RFC, but I just don't know and I could see various good and bad answers being possible here. 3777 says that: "The nominating committee should archive the information it has collected or produced for a period of time not to exceed its term." I don't know what's actually done now, but could imagine that tools might make it better or worse.
      - Section 2, will those URLs containing 2011 remain good for sufficiently long to be useful? Maybe s/2011/2012/ at least.
      - Section 4, "should be stored using an encrypted cookie" is wrong. Cookies may disappear (e.g. in http/2.0) and other better technologies might come along.
      - Section 4, I think you need to say somewhere that each nomcom MUST use a different key pair.
      - Section 4, s/using the procedure/for example, using the procedure/ would be better.
      - 2119 and 3777 should be referenced somewhere in the text I guess.
      - Section 4, I think you need to say somewhere that each nomcom MUST use a different key pair.
      - Section 4, s/using the procedure/for example, using the procedure/ would be better.
    8. Brian Haberman: Comment [2012-07-12]:
      I support the publication of this document and only have the following, non-blocking, comments:
      1. The last sentence of the Introduction is missing a period.
      2. Why does the security section start numbering at 000 and all the other sections start at 001?
      3. With AD-006, is there a need to allow for the specification of time windows when generating statistics?
      4. AD-002 refers to "Acceptances and declines". Is there a reason for the capitalization of "Acceptances", but not of "declines"?
      5. The QR requirements also mix and match capitalization of "Questionnaires".
      6. I support Barry's feedback on the use of 2119 keywords when referring to the management of the key and encrypted cookie.
    9. Barry Leiba: Comment [2012-06-13]:
      Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them:
      Section 3: Is there really no need for a fourth "Nomcom advisor or liaison" role?
      Sec-004: The MUST in the second sentence is silly: this isn't a normative command, but a simple statement, "This key will be used to decrypt...." But in the third sentence, shouldn't it be, "Once entered, this key MUST be stored using an encrypted cookie?", rather than "should be stored"?
      Section 6: It's not clear to me why there's a difference between a community member entering a nomination and a Nomcom member doing it. Maybe you can explain that a little more, briefly.
      QR-002 & QR-006: Please make it clearer what the substantive difference is between these two.
      Other comments; no need to respond to these. Take them or modify them as you please:
      Auth-003: Maybe it's just me, but I found that I had to read the "to be provided" bits a few times before I correctly parsed them. "To be given" or "to get" sounds better to me.
      AD-004: I don't think "allow <infinitive>" is proper usage, though it's common. Anyway, to make it parallel to the other items, how about, "allow the viewing of a list..."?
      Appendix A: Typo "pait" -> "pair"
    10. Martin Stiemerling: Discuss [2012-07-17]:
      Most of the issues are already covered by other COMMENTs raised about this draft, but:
      Section 3., paragraph 2:
      "o AUTH-001: The tool MUST allow the members of the community to login with their existing datatracker.ietf.org credentials.
      "o AUTH-002: The tool MUST allow the members of the community to create a new login with an automated system. The system MUST verify that e-mail address used for creating the login.
      What does 'verify that e-mail address' mean? Verify for correctness of the syntax? I guess not. This could be clarified to 'MUST verify that the email address is in existence'.
      Section 5., paragraph 2:
      "o NOM-001: The tool MUST allow the members of the community to enter nominations into the Public Nomcom tool."
      "o NOM-002: The tool MUST allow the members of the Nomcom to enter nominations into the Private Nomcom tool. The tool MUST allow the Nomcom member to optionally enter information about the originator of the nomination. The tool MUST record the identity of the originator of the nomination for audit purposes."
      Does the second MUST about the identity also apply to NOM-001? And isn't a further NOM- requirement?
      "o FB-006: The tool MUST allow the Nomcom chair to manually move any of the archived mails into the feedback section of one or more nominees for one or more open positions. This is required because a single email may contain feedback concerning more than one nominee or more than one open position."
      Moving an email implies removing it from the archive? Or is it meant to say "copy"?
      Section 9., paragraph 1:
      "The tool must authenticate all users and must allow classifying logins into 3 roles. Nomcom chair, Nomcom member and community member. All communications to/from the Nomcom and among the members of the Nomcom must be stored in an encrypted form."
      What about a role 'liaison'? This role seems to be distinct from the other roles.
    11. Martin Stiemerling: Comment [2012-07-17]:
      **Editorals:
      Section 1., paragraph 1:
      "The IETF Nominations Committee (Nomcom) is a body that selects candidates for the open IESG, IAB and IAOC positions. There is a need for a set of tools to aid the Nomcom to operate efficiently. This document lays out a few requirements for such a tool"
      s/a few requirements/a set of requirements/
      s/tool/tool./
      "o AD-005: The tool MUST allow the reporting of accepance or decline status both per nominee as well as per open position."
      s/accepance/acceptance/
      "o QR-004: The tool MUST keep track of the questionnaire receipt status for the nominees. The filled in questionnaires are received as emails to the Nomcom mailing list."
      Sent to the Nomcom mailing list, isn't it?
    12. Sean Turner: Discuss [2012-07-17]:
      Okay so I know it's just an example in Appendix A, but I bet everybody will use it. Therefore, we'd better make sure to specify SHA-256 because SHA-1 is the default (more on that in the comments).
      Does the key you just made need to be password protected? The examples don't show it being encrypted and I don't turn PBE on in the one-step command. If it is supposed to be encrypted let me know and we can tweak the commands.
    13. Sean Turner: Comment [2012-07-17]:
      (many items, see link)

    Telechat:

  4. Publishing the "Tao of the IETF" as a Web Page (Informational)
    draft-hoffman-tao-as-web-page-03
    Token: Russ Housley
    Discusses/comments (from ballot draft-hoffman-tao-as-web-page):
    1. Benoit Claise: Comment [2012-07-13]:
      My four points are not really a DISCUSS, but I really would like to see it addressed, or at least discussed
      1. This document has two parts, a correctly explained in the Introduction section.
      - it explains that the "Tao of the IETF", which has been published as a series of RFCs in the past, is now published as a web page.
      - it explains the new procedure. "This document contains the procedure agreed to by the IESG"
      My issue is: The abstract only contains the first part 1. Here is a proposal:
      OLD: This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, will instead be published as a web page.
      NEW: This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead published as a web page. Furthermore, this document contains the procedure for publishing and editing the Tao
      2. Why do you always use the future tense in the draft?
      - "This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, will instead be published as a web page."
      - "The Tao will be published at lt;http://www.ietf.org/tao.html>" (note: it's done right in the security considerations section
      - etc...
      Specifically for the section 2, the procedure should really use the present tense.
      OLD: The Tao will be edited by one person who is chosen by the IESG.
      NEW: The Tao is edited by one person who is chosen by the IESG.
      3. I would make sense to set up the mailing in advance and mentioned it in draft
      "The Tao will be edited by one person who is chosen by the IESG. Suggestions for changes to the Tao will be discussed on an open, Tao-specific mailing list."
      4. "Each version of the Tao will have a visible timestamp near the beginning of the document. All published versions will be archived using URLs of the form <http://www.ietf.org/tao-archive/tao-YYYYMMDD.html>."
      If there is right now http://www.ietf.org/tao-archive/tao-20120713.html, how do I know the date of the previous version? I guess that the http://www.ietf.org/tao-archive/ directory will list all the entries, right? If this is the case, please mention it in the draft
    2. Adrian Farrel: Discuss [2012-07-18]:
      I support the publication of this document. Before moving to a "Yes" ballot, I would like to discuss how translations that are produced from time to time will be made available and archived
    3. Adrian Farrel: Comment [2012-07-18]:
      Unclear to me why the document needs to limit the edit team to exactly one person for all time. Suggest "one or more people as designated by the IESG"
    4. Barry Leiba: Comment [2012-06-15]:
      Gotta love the Security Considerations section. :-)
    5. Martin Stiemerling: Comment [2012-07-16]:
      The draft says in Section 2 "is based on the last Internet-Draft that was meant to replace". Should we add, just for completeness, an informational reference to this draft?
      Otherwise, this draft might be hard to spot.
      However, this might be only of interest to archaeologists...

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1306 EDT break

1311 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

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. Confirm Designated Expert for the vCard Elements Registries (Pete Resnick)

    Telechat:

  2. Assignment of Expert Reviewer (FLUTE Content Encoding Algorithms registry) (Martin Stiemerling)

    Telechat:

  3. Review of Standards Organization: the IEEE Industry Standards and Technology Organizations [IANA # 565794] (Michelle)

    Telechat:

  4. Review of Standards Organization: ISO/IEC JTC1/SC29 [IANA # 584312] (Michelle)

    Telechat:

7. Agenda Working Group News

1339 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-07-19 07:31:29 PDT)

draft-sakane-dhc-dhcpv6-kdc-option

  1. Adrian Farrel: Comment [2012-07-19]:
    Would you mind rewriting the Abstract for clarity? Something like...
    
    
    
       This document defines four new options for the Dynamic Host
    
       Configuration Protocol for IPv6 (DHCPv6).  These options are used to
    
       carry coniguration information for Kerberos.
  2. Barry Leiba: Comment [2012-07-14]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- Section 4 --
    
    I find the use of 2119 language a bit odd in the second and third paragraphs. 
    
    You use MUST for what the client sends to the server, and you don't use 2119
    
    language for how the server responds.  In fact, I think it would be fine to
    
    strike the MUSTs from the client side too.  For example, this works fine for
    
    the third paragraph:
    
    
    
       If a client requires configuration parameters for a KDC, the client
    
       sends a DHCPv6 ORO specifying the Kerberos KDC Option.  The
    
       client MAY include a Kerberos Principal Name Option.  The client
    
       MAY include a Kerberos Realm Name Option.
    
    
    
    That makes it parallel to the protocol instructions for the server.
    
    
    
    I also find the MUST in the fifth paragraph to be odd, but it matches the 2119
    
    language in RFC 2782, so I can't really pick any bones with it.
    
    
    
    The MUST in Section 4.1 is stranger still:
    
       The
    
       administrator of the realm MUST define the method as part of the
    
       configuration of the client before the client is installed.
    
    
    
    I don't know how that qualifies as a MUST, how it has anything to do with
    
    interoperability, nor how it could be detected or enforced.  Wouldn't it be
    
    suitable to just say that "the administrator of the realm usually defines the
    
    method [...]" ?
    
    
    
    -- IANA Considerations --
    
       The assignment of future entries is by "IETF Consensus" policy as
    
       described in BCP 26 [RFC5226].
    
    
    
    In RFC 5226 this is called "IETF Review", not "IETF Consensus"; please change
    
    that.
  3. Pete Resnick: Comment [2012-07-18]:
    I agree with Barry's concerns. Please address them.
  4. Martin Stiemerling: Comment [2012-07-17]:
    [updated, as the IANA part takes care all of stuff to be registered.]
    
    
    
    Please reply to these comments, as they are substantial for the document:
    
    
    
    Section 3., paragraph 7:
    
    
    
    >    With the exception of the Kerberos KDC Option, none of these options
    
    >    may appear more than once in a DHCPv6 message.
    
    
    
      Shouldn't this read 'MUST NOT appear'?
    
    
    
    Appendix B., paragraph 1:
    
    
    
    >    When no criteria have been specified and the client could get the
    
    >    Kerberos information from either the DNS server or the DHCPv6 server,
    
    >    then the information from DNS should be preferred.  The following is
    
    >    the guideline for the client in such an environment.
    
    
    
      This appendix is not meant to be the standard, but rather
    
      informational, isn't it? If it is this way, please state it
    
      explicitly!
  5. Sean Turner: Comment [2012-07-18]:
    Updated based on email exchange with Sam.
    
    
    
    1) a: r/defines new four/defines four new
    
    
    
    2) s2: If you going to have the following:
    
    
    
     It is assumed that the readers are familiar with the terms and
    
     concepts described in DHCPv6 [RFC3315].
    
    
    
    You might as well throw in [RFC2782], [RFC3315], and [RFC4120] ;)
    
    
    
    3) s3: r/DHCP configuration parameters/DHCPv6 configuration parameters
    
    
    
    4) s3.3: You need to leave a marker for IANA to fill for the number it assigns:
    
    
    
    OLD:
    
    
    
    The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME.
    
    
    
    NEW:
    
    
    
    The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (TBD by IANA).
    
    
    
    5) s3.4: should DTLS be in the list?
    
    
    
    6) s3.4: r/realm- name/realm-name
    
    
    
    7) app a: It's unclear to me why you need this appendix.  The reason is clearly
    
    stated in s1.
    
    
    
    If the app a remains:
    
    
    
    8) app a, s1: It's probably be better to say:
    
    
    
      This appendix gives reasons why DHCP-based KDC discovery
    
      *can be* more appropriate for industrial systems
    
      than DNS-based KDC discovery (as described
    
      in RFC4120 - the "RFC4120-way").
    
    
    
    I'm suggesting this because I'm not entirely sure it always "is" better to use
    
    DHCP over DNS in an industrial system.
    
    
    
    and:
    
    
    
      *Some* Industrial systems have their own name spaces and
    
      naming systems which are not based on FQDN and DNS.
    
    
    
    Do they all have their own?
    
    
    
    9) app a, s1: What kind of server are we getting rid of if we're using
    
    DHCP-based KDC discovery over DNS-based discovery.
    
    
    
      DHCP-based KDC discovery is more efficient because
    
      reducing the number of servers reduces the number of
    
      messages, improves reliability and reduces management cost.
    
    
    
    Also the above seems a bit lit marketing to me.
    
    
    
    10) app a, s2 & s3: Not sure why these paragraphs are here.  The heart of
    
    matter is in s4 - fielded devices don't support FQDN/DNS hence you need a DHCP
    
    mechanism.  You're goal is to not replace all the currently fielded devices
    
    because it's too darn expensive.
    
    
    
    In s2 it might be worth making the following change before the bullets:
    
    
    
      Field devices currently deployed where DHCP-based KDC discovery can be more
    
      appropriate than DNS-based KDC discovery have the following
    
      characteristics:
    
    
    
    In s3: Why is this paragraph needed at all.  It doesn't fit under the heading
    
    of "Why DNS is not acceptable in some environments".  Seems like marketing to
    
    me.
    
    
    
    11) app a, s5: How are less servers being implemented?
    
    
    
    12) app a, s6: There's a whole 'lotta references in Appendix A that need to be
    
    added in s8.2.

draft-ietf-behave-lsn-requirements

  1. Ronald Bonica: Discuss [2012-07-13]:
    Section 5, as it is currently composed, strays from requirements into potential
    
    solutions.
    
    
    
    From the perspective of a requirements document, Section 5 is really about:
    
    
    
    - a port utilization requirement
    
    - a log volume requirement
    
    - a security / port guessing requirement
    
    
    
    All of these should be called out as real requirements (REQ-xx). A discussion
    
    of these requirements should mention that they compete with one another. An
    
    implementation optimizes to satisfy one requirement at the expense of another.
    
    Therefore, these are soft requirements (SHOULD as opposed to MUST).
    
    
    
    It might be OK to mention that an implementation's choice of port allocation
    
    scheme influences which requirement gets priority. However, when we mention
    
    three specific port allocation schemes (traditional, scattered and consecutive)
    
    we put one toe out of bounds. When we make statement about which scheme
    
    optimizes for which requirement, the rest of the body follows the toe.
    
    
    
    Honestly, I would have never noticed this problem had it not been for the IPR
    
    declaration and the authors assumption that the IPR related to Section 5. But
    
    one closer examination, the section has a problem, regardless of the IPR.
  2. Ronald Bonica: Comment [2012-07-18]:
    Agree with Russ that this document should be INFORMATIONAL
  3. Stewart Bryant: Comment [2012-07-17]:
    I agree with Russ's DISCUSS concerning the classification of
    
    this document as BCP. Informational seems more appropriate.
    
    
    
    ===
    
    
    
    Why does REQ-1 not also specify  draft-ietf-behave-sctpnat-06?
    
    
    
    ===
    
    
    
    Limiting the rate of allocation is intended to prevent
    
          against CPU resource exhaustion.
    
    
    
    d/against/
    
    
    
    ====
    
    
    
    REQ-12:  A CGN SHOULD NOT log destination addresses or ports.
    
    
    
       Justification:  Destination logging at the CGN creates privacy
    
          issues.
    
    
    
    Why is this not "SHOULD NOT log destinations addresses or
    
    ports unless required to do so for administrative reasons"
    
    followed by  privacy advice?
    
    
    
    As much as the IETF finds it distasteful, this sort of logging
    
    may well be administratively required at number of levels,
    
    and we should deal with minimizing the privacy issues
    
    when this happens.
    
    
    
    ====
  4. Ralph Droms: Discuss [2012-07-16]:
    I want to discuss the indication that this document updates RFC 4787.
    
    My position does not require any changes to the document by the
    
    authors at this time.
    
    
    
    In my opinion, this document builds on RFC 4787 to list requirements
    
    for use cases or deployment scenarios not in the scope of RFC 4787,
    
    but does not update or replace any of the text in RFC 4787.  While
    
    a couple of requirements in this document are described as "stronger
    
    versions" of the corresponding requirements from RFC 4787, I don't see
    
    any indication that these modified requirements are to be
    
    retroactively applied to RFC 4787.
    
    
    
    If it does update RFC 4787, exactly what text in RFC 4787 updated with
    
    new text from this document?
  5. Stephen Farrell: Discuss [2012-07-14]:
    (1) As written, REQ-1 is followed by a MUST that applies to
    
    anyone who ever writes a NAT-considerations for any transport
    
    protocol for all time. (Even though CGN is presumably a
    
    transition technology intended to vanish in a decade or so
    
    when IPv6 is everywhere.) That seems wrong in lots of ways.
    
    In fact it seems backwards. Oughtn't the onus be on CGN folks
    
    to update to meet the needs of new transports and not the
    
    other way around and oughtn't CGN be designed so as to work
    
    (to the maximum extent possible) with any transport that we
    
    can now envisage.  If in fact its not possible for a GGN to
    
    be designed to be friendly towards future transport networks,
    
    then the argument that that is the case needs to be made.
    
    (And be convincing if you want the MUST this way about.) I'm
    
    not sure what kind of change might help out here but I think
    
    some change is needed.
    
    
    
    (2) REQ-4 calls for "limits ... per transport protocol" in
    
    bullet B. Is that meant to be per-subscriber? If so, why are
    
    you limiting how a subscriber chooses to use their bandwidth
    
    on a per-transport protocol basis? If not, then it really
    
    seems like a different requirement that is not part of REQ-4
    
    and is very odd - why would a CGN want the set of subscribers
    
    behind it to use e.g. 50% less UDP than TCP?
    
    
    
    (3) Does REQ-7 mean "CGNs SHOULD use EIF"? Its not clear to
    
    me if you mean that, or if you mean "CGNS SHOULD implement
    
    EIF"? I think "RECOMMENDED [to] ...  have... behaviour" is
    
    ambiguous.
    
    
    
    (4) cleared
    
    
    
    (5) I agree with the changes suggested by Sam Hartman in his
    
    secdir review for REQ-9 and section 8. [1] Sam suggested text
    
    that'd work for me, and the authors seem receptive but I'm
    
    not clear if the discussion has converged or not. (I expect
    
    it will, so this mainly for tracking.)
    
    
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03392.html
  6. Stephen Farrell: Comment [2012-07-14]:
    - Ought you do s/must/MUST/ in "In other words, a CGN must
    
    use the same external IP address mapping for all sessions
    
    associated with the same internal IP address, be they TCP,
    
    UDP, ICMP, something else, or a mix of different protocols."
    
    
    
    - s/rarity of/scarcity of new/ after REQ-3. They're not rare,
    
    we see 'em all the time, but new ones are scarce.
    
    
    
    - The justification for REQ-4 seems confused, in particular
    
    the last sentence about CPU consumption doesn't seem to
    
    relate to port consumption at all. The justification for
    
    REQ-5 seems to make a similar error, saying CPU consumption
    
    when memory consumption is at stake.
    
    
    
    - REQ-8 seems to use the terms deallocated and state loss as
    
    if they're synonyms. Are they? If so, then using one term is
    
    probably better. If not, then maybe say how they differ. The
    
    justification text just before REQ-9 seems to say they
    
    differ. You also have 2119 keywords in the justification text
    
    here, which you seem to have tried to avoid elsewhere so
    
    maybe some edits are needed?
    
    
    
    - Section 4 could note that logging mappings might also cause
    
    privacy issues, e.g. the pattern of a subscriber's behaviour,
    
    and that logs need to be protected.
    
    
    
    - I think you could explain more why small consecutive port
    
    sets provide poorer security.
    
    
    
    - I'm also a bit wary of the IPR declaration here. If that
    
    could be clarified some more or if the WG could now see a
    
    published application, that'd be great. But I accept that
    
    that WG have chosen to go ahead as-is.
  7. Brian Haberman: Comment [2012-07-12]:
    1. In section 3, the text states "If NAT behavioral requirements documents are
    
    created for additional protocols, then these new documents MUST update this
    
    list by adding themselves to it."  Do these new behavioral requirements
    
    documents need to update this document?  Does this document need to be updated
    
    each time a new behavioral document is published as an RFC?
    
    
    
    2. For REQ-6, what is the impact of disabling translation on state tables
    
    within the NAT?  If no state is maintained, is there a DoS vulnerability for
    
    the client?  For example, if I know that traffic from X2:x2 --> X1:x1 is not
    
    translated, could I use that knowledge to attack the client?
    
    
    
    3. REQ-8 recommends not re-using a port until 120 seconds elapses.  Is that
    
    value applicable to all transport protocols?  How do you envision a CGN
    
    enforcing that value after a crash (as mentioned in the last paragraph of the
    
    requirement justification)?
  8. Russ Housley: Discuss [2012-07-14]:
    
      In the Gen-ART Review by Alexey Melnikov on 3-July-2012, he asked:
    
      >
    
      > I found it is to be odd to have a requirements document as a BCP,
    
      > but I am sure you can sort the right status out with IESG.
    
      >
    
      The authors made no attempt to encourage the publication as BCP.  They
    
      appear to be satisfied with either BCP or Informational.  Requirements
    
      documents are normally published as Informational RFCs.  I see no
    
      reason for an exception in this case.
  9. Barry Leiba: Comment [2012-07-11]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- REQ-5 --
    
          It is at the SHOULD level to account for the
    
          fact that means other than rate limiting may be used to attain the
    
          same goal.
    
    
    
    It seems, then, that there is a higher-level requirement that's missing, and
    
    that this "requirement" is really stating a suggested means to achieve it.
    
    
    
    UPDATE: Simon explains that "It" in the above quotation refers to list item B
    
    only.  I'm requesting that he change "It" to "Item B" to make that clear.
    
    
    
          This state consumes resources for which, in the
    
          case of a CGN, subscribers may compete.  It is necessary to ensure
    
          that each subscriber has access to a fair share of the CGN's
    
          resources.  Limiting TCP sessions per subscriber and per time unit
    
          is an effective mitigation against inter-subscriber DoS attacks.
    
    
    
    UPDATE: Simon also explains that the last sentence in the paragraph above needs
    
    to be removed.
  10. Pete Resnick: Comment [2012-07-17]:
    For the IESG: Perhaps I'm just being contrarian today, but I *do* think this
    
    document should be BCP and not Informational. It is not a requirements document
    
    in the sense that it is laying out requirements for future protocol documents
    
    being developed by a WG; it is a consensus document listing the requirements
    
    for the operation and administration of a type of device. If that doesn't fall
    
    within the 2nd paragraph of RFC 2026 section 5, I don't know what does.
    
    
    
    For the authors/WG: I agree with Stephen's point about REQ-1, but disagree with
    
    the solution suggested on the IESG list; I think it reversed the sense of the
    
    statement. You had:
    
    
    
    OLD:
    
    
    
               If NAT behavioral requirements documents are created for
    
               additional protocols, then these new documents MUST update
    
               this list by adding themselves to it.
    
    
    
    NEW:
    
    
    
               Any future NAT behavioral requirements documents for IPv4
    
               transport protocols will also need to consider the
    
               requirements for CGNs stated here.
    
    
    
    But this loses the sense that new NAT behavioral requirements documents will
    
    impose new requirements on CGNs. Might I instead suggest:
    
    
    
               Any future NAT behavioral requirements documents for IPv4
    
               transport protocols will impose additional requirements for
    
               CGNs on top of those stated here.
    
    
    
    The requirement is not a requirement for future documents; it's a requirement
    
    for CGNs.
  11. Robert Sparks: Comment [2012-07-18]:
    I share Ralph's question about how this updates RFC4787.
    
    
    
    It worries me that we are requiring the implementation of a new protocol (pcp)
    
    as part of a BCP. It would be more work to write "you need to do all the things
    
    pcp lets you do", but it would be more in the spirit of RFC4787 to have done so.
  12. Martin Stiemerling: Discuss [2012-07-17]:
    Updated my position, after reading REQ-9 again:
    
    
    
    >> Section 3., paragraph 42:
    
    >
    
    >>>     REQ-9:  A CGN MUST include a Port Control Protocol server
    
    >>>             [I-D.ietf-pcp-base] with the following constraints on its
    
    >>>             behavior:
    
    >>
    
    >>    Is this saying that each and every CGN MUST have PCP or that CGN
    
    >>    implementing PCP must follow the constraints?
    
    
    
    > Each and every CGN MUST have PCP and MUST follow the constraints. I'll
    
    > fix the text in a later revision.
    
    
    
    Can we mandate a specific protocol to be used for this or can we only mandate
    
    that such a type of protocol is being used? I don't see the IETF in the
    
    position to mandate this type of protocol for CGNs.
    
    
    
    There are other protocols out there which might be suitable. Note that I am
    
    co-author of some, but this isn't the reason for the question. I do not get any
    
    reward if I promote these protocols.
    
    
    
    It is more:
    
    do we need to constrain CGN deployments to a protocol (PCP) which is developed
    
    right now, or are we open to existing or future protocols, or whatever folks
    
    deploying this deem right?
    
    
    
    I would propose to change REQ-9 to :
    
    REQ-9: A CGN MUST include a middlebox control protocol that allows manipulation
    
    of CGN bindings with the following contstraints <list items A and B> REQ-9a: If
    
    PCP is used these contstraints MUST be applied in addition to contraints A and
    
    B: <list items C and D>
  13. Martin Stiemerling: Comment [2012-07-18]:
    I am fine with this being BCP.  (the prior version of the ballot was a typo)
    
    
    
    Section 3., paragraph 50:
    
    
    
    >    REQ-10:  CGN implementrers SHOULD make their equipment manageable.
    
    >             Standards-based management using standards such as
    
    >             "Definitions of Managed Objects for NAT" [RFC4008] is
    
    >             RECOMMENDED.
    
    
    
      s/implementrers/implementers/
  14. Sean Turner: Discuss [2012-07-18]:
    1) s4: Shouldn't the requirements for the timestamp be identical to the
    
    requirement in 6302:
    
    
    
       A timestamp, RECOMMENDED in UTC, accurate to the second, from a
    
       traceable time source (e.g., NTP [RFC5905]).
    
    
    
    2) s4: doesn't transport protocol need to be added to the list?
  15. Sean Turner: Comment [2012-07-18]:
    s4: Because you gave an out in the previous paragraph it's worth noting in the
    
    following that one reason might be that the CGN isn't following 6302:
    
    
    
      This requirement is at the SHOULD level to account for the fact
    
      that there may be other reasons for logging destination addresses
    
      or ports.

draft-ietf-6lowpan-btle

  1. Stewart Bryant: Discuss [2012-07-17]:
     Bluetooth Special
    
       Interest Group [BT-SIG] has introduced two trademarks, Bluetooth
    
       Smart for single-mode devices (a device that only supports BT-LE) and
    
       Bluetooth Smart Ready for dual-mode devices.
    
    
    
    If these are trademarks, as opposed to device class names, have we represented
    
    the trademarked name in the legally accepted format? Do we need to represent
    
    "Bluetooth" in a format to identify it as a trademark term?
    
    
    
    =======
  2. Wesley Eddy: Comment [2012-07-17]:
    Figure 3 seems to suggest that TCP or UDP are the only supported transports,
    
    and that there are no applications above them, or other tunneling possible.  I
    
    think the figure should just show a generic "upper layer protocols" blob on top
    
    of IPv6, or just end the stack at IPv6 unless the capability is really
    
    restricted to just TCP and UDP, no ICMPv6, etc., which doesn't seem right.
  3. Adrian Farrel: Comment [2012-07-19]:
    On the whole, I am supportive of this document, and there are enough
    
    Discusses covering the main issues. Please consider my Comments some of
    
    shich may help resolve those Discusses.
    
    
    
    ---
    
    
    
    I am a little confused about the difference between "Bluetooth 4.0" and
    
    "BT-LE."
    
    
    
    The Abstract adds to this confusion...
    
    
    
       The low power variant of Bluetooth is
    
       commonly specified in revision 4.0 of the Bluetooth specifications
    
       and commonly refered to as Bluetooth 4.0.
    
    
    
    1. s/commonly specified/currently specified/  ?
    
    
    
    2. Is the low power version of Bluetooth commonly refered to as
    
       Bluetooth 4.0 as the text appears to say? If so, why do you
    
       consistently refer to BT-LE instead?
    
    
    
    Section 2, on the other hand, suggests that BT-LE is only a part (albeit
    
    integral) of the Bluetooth 4.0 spec.
    
    
    
    ---
    
    
    
    I see no reason to refer to the "Bluetooth Smart" and "Bluetooth Smart
    
    Ready" trade names. Only one is used in the document, and could easily
    
    be replaced with real text. Cleaning this up would avoid the issues of:
    
    - a reference that is a URL and not a pointer to a document
    
    - the whole trademark issue
    
    
    
    ---
    
    
    
    Section 2.3
    
    
    
       This specification mandates that the
    
       Bluetooth Device Address MUST be a public address.
    
    
    
    Asphrased, this implies that you are changing the BT 4.0 spec (which is
    
    not your intention and would not go down well!). I think what you mean
    
    is:
    
    
    
       This specification mandates that Bluetooth devices transmitting IPv6
    
       packets in conformance with this specification MUST use a Bluetooth
    
       Device Address that is a public address.
    
    
    
    ---
    
    
    
    Section 3.1 and Section 4
    
    
    
    I do not think this document should attempt to specify (or discuss) code
    
    points that will be allocated by other bodies.
  4. Stephen Farrell: Discuss [2012-07-16]:
    
    In figure 5 the 6LBR is the BTLE-Master and the gateway to
    
    the Internet, which is a reasonable choice, but why is it the
    
    only choice? Are there no scenarios where a BT-LE slave
    
    wouldn't have another i/f and so be able to act as a g/w to
    
    the Internet, e.g. when the BTLE-Master doesn't have an
    
    Internet connection? Why rule that out? There may well be
    
    good reasons but it wasn't clear to me.
    
    
    
    I guess another way to ask this is to ask why you can't
    
    support this diagram:
    
    
    
                  h                 ____________
    
                   \               /            \
    
             h ---- Master -- h -- |  Internet  |
    
                   /               \____________/
    
                  h
  5. Stephen Farrell: Comment [2012-07-16]:
    
    - The "MUST be reserved by the BT-SIG" in 3.1 is odd. Why
    
    haven't they already? Is this text meant to go into the RFC
    
    or not?  I'd hope not and that we'd hold the RFC until
    
    they've allocated an ID for us.  So I agree with Barry's
    
    discuss on this.
    
    
    
    - Shouldn't you provide a reference to where you can go see
    
    the BT-SIG allocation? I did go looking for a few minutes and
    
    its non trivial to find. (In a few minutes:-)
    
    
    
    - Is the channel ID in 3.1 for IPv6 of all kinds, or only for
    
    IPv6 as discussed in this spec? I think that needs to be
    
    clear in this spec.
    
    
    
    - The text describing Figure 3 might be better to say that
    
    TCP & UDP are just examples.
    
    
    
    - 3.2.1: says "MUST NOT use more than one IID" - presumably
    
    that means at a given moment? When is it ok to change?
    
    
    
    - End of 3.2.1: s/draft/specification/
    
    
    
    - 3.2.3: Is "elided" clear enough? I guess it might be if
    
    you're familiar with 6lowpan, but if not maybe more's needed.
    
    Maybe give a reference to where how to do that is defined.
    
    
    
    - 3.2.3: Is "global IPv6 address" right there? Couldn't it be
    
    some other special kind of address?
    
    
    
    - nits via secdir review:-)
    
    
    
    gateway^1s => gateway's
    
    respectively => respectively
  6. Brian Haberman: Discuss [2012-07-18]:
    I support the publication of this document, but there are some issues that need
    
    to be DISCUSSed...
    
    
    
    1. This is probably related to Stephen's DISCUSS on which types of nodes can
    
    act as Internet gateways. The second paragraph of Section 3 says that BT-LE
    
    does not support the formation of multihop networks.  I assume this is implying
    
    multihop at the Bluetooth layer and not the IP layer since the spec later talks
    
    about forwarding IPv6 packets between master nodes. This should be stated more
    
    clearly in the text.  As a follow-on, does this multihop limitation also mean
    
    that slave nodes can only have a single interface (thus eliminating Stephen's
    
    alternative gateway location architecture)?
    
    
    
    2. Section 3.2.1 states that IPv6 over BT-LE will perform SLAAC as defined in
    
    RFC 4862.  Given the limited topology of BT-LE, is there a reason to perform
    
    all of 4862?  Since section 3.2.2 requires a node to register its address with
    
    the master, is there a need to perform DAD on the point-to-point link between
    
    the master and slave?  The 802.15.4 spec needs that capability because of the
    
    potential to operate in a mesh topology, but it really isn't needed in the star
    
    topology.
    
    
    
    3. Related to Sean's DISCUSS on header compression... The opening sentence of
    
    section 3.2.3 does not make sense.  Why does it say "This document assumes
    
    [RFC6282]..."?  As a protocol specification, it specifies what is to be used. 
    
    Something along the lines of "Header compression, as defined in RFC 6282 is
    
    REQUIRED..." would be more appropriate.
  7. Brian Haberman: Comment [2012-07-18]:
    1. The Abstract can be dramatically condensed.  I don't see a reason to spend
    
    time in this section discussing the differences between BT-LE and base
    
    Bluetooth.
    
    
    
    2. I agree with Russ' DISCUSS point about the abstract nature of the first
    
    paragraph in Section 3.  This spec needs to explicitly indicate which parts of
    
    the referenced specs apply to each of the mentioned technology areas.
    
    
    
    3. Section 3.2.1 says that a node SHOULD use its EUI-64 for SLAAC.  Is there a
    
    scenario you can provide in the draft as an example where that SHOULD can be
    
    ignored?  RFC 3041 addresses come to mind.
    
    
    
    4. The discussion of DHCPv6 Prefix Delegation should include an Informative
    
    reference to RFC 3633.
    
    
    
    5. Figure 4 really adds nothing to the document since the link-local address
    
    format is not changed from what is in RFC 4291.
  8. Russ Housley: Discuss [2012-07-17]:
      I have selected portions of the Gen-ART Review from Brian Carpenter
    
      that meet the DISCUSS Criteria.  From my perspective, it would have
    
      been much simpler for the authors to respond to these comments when
    
      they were first posted during IETF Last Call.
    
    
    
      (1) Section 3.1 includes this paragraph:
    
    
    
      "In order to enable transmission of IPv6 packets over BT-LE, a new
    
      fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT-
    
      SIG.  A request for allocation of a new fixed channel ID for IPv6
    
      traffic by the BT-SIG should be submitted through the liaison process
    
      or formal communique from the 6lowpan chairs and respective area
    
      directors.  Until a channel ID is allocated by BT-SIG, the channel ID
    
      0x0007 is recommended for experimentation.  Once the channel ID is
    
      allocated, the allocated value MUST be used."
    
    
    
      Let's wait for needed L2CAP Channel ID to be allocated, and then
    
      publish a standards-track RFC.
    
    
    
      (2) Section 3 includes this paragraph:
    
    
    
      "BT-LE technology sets strict requirements for low power consumption
    
      and thus limits the allowed protocol overhead. 6LoWPAN standards
    
      [RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic
    
      functionality like header compression, link-local IPv6 addresses,
    
      Neighbor Discovery and stateless IP-address autoconfiguration for
    
      reducing the overhead in 802.15.4 networks.  This functionality can
    
      be partly applied to BT-LE."
    
    
    
      This is not the Introduction section, when an unclear statement like
    
      this might be acceptable.  Three normative references are provided,
    
      but we are told that they are "partly applied".  An implementer is not
    
      given enough information to build interoperable implementations.
    
      Brian suggested text; however, I would strongly prefer a pointer to
    
      a subsection for each normative reference.
  9. Barry Leiba: Discuss [2012-07-11]:
    This is a procedural issue:
    
    -- Section 3.1 --
    
       In order to enable transmission of IPv6 packets over BT-LE, a new
    
       fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT-
    
       SIG.  A request for allocation of a new fixed channel ID for IPv6
    
       traffic by the BT-SIG should be submitted through the liaison process
    
       or formal communique from the 6lowpan chairs and respective area
    
       directors.  Until a channel ID is allocated by BT-SIG, the channel ID
    
       0x0007 is recommended for experimentation.  Once the channel ID is
    
       allocated, the allocated value MUST be used.
    
    
    
    1. The first MUST is inappropriate: we don't have any standing to make a
    
    normative requirement on the BT-SIG.  What you *mean*, I think, is simply that
    
    we have to get a channel ID allocation (a demand on the 6lowpan chairs, I
    
    guess, to handle that), and then we MUST use it (the second MUST covers that
    
    part).
    
    
    
    2. Has this request been made?  If so, what is its status (neither the document
    
    nor the shepherd writeup says)?  If not, when is that planned to happen? 
    
    Should I hold this DISCUSS as a reminder for it to be done?  Or does that
    
    request have to wait until after this document is published (in which case, how
    
    do we track it)?
    
    
    
    3. Does it fit into BT-SIG's procedures to use 0x0007 for now, or are we
    
    proposing to "squat" on one of their code points with that recommendation, in a
    
    way they would disapprove of?
  10. Barry Leiba: Comment [2012-07-11]:
    Non-blocking, and no need to respond to these:
    
    
    
    -- Section 3.2.1 --
    
       The used IPv6 prefix
    
       may change due to the gateway^1s movement.
    
    
    
    Nit: you appear to have a funny apostrophe there.
    
    
    
    -- Section 3.2.3 --
    
       It is required that all
    
       headers MUST be compressed according to HC base encoding.
    
    
    
    Nit: "required" is also a 2119 term, so you don't need both it and MUST.  I
    
    suggest one of these: a. All headers MUST be compressed according to HC base
    
    encoding. b. It is REQUIRED that all headers be compressed according to HC base
    
    encoding.
    
    
    
    There's a similar sentence in 3.2.4 that could use the same treatment.
  11. Pete Resnick: Comment [2012-07-17]:
    Section 2 is generally an overview of BT-LE. I'm not a big fan of doing
    
    technology overviews in specifications; I say just get to the protocol and give
    
    a reference or appendix for overviews.
    
    
    
    That said, I worry that there are 4 MUST/MUST NOT requirements in 2.3 and 2.4.
    
    If people see section 2 as purely overview, they may miss these requirements.
    
    I'd suggest moving the requirements into section 3 (the specification) to make
    
    sure that nobody misses them.
  12. Martin Stiemerling: Comment [2012-07-17]:
    In full support of Barry's point on Section 3.1.
  13. Sean Turner: Discuss [2012-07-17]:
    So this is probably a lame discuss, but I can't figure it out.   In s3.2.3, you
    
    say "all headers MUST be compressed according to HC base encoding".  But, in
    
    RFC 6282 there's IPHC, HNC, and IPv6 Header Encoding.  Which one is the HC base
    
    encoding?  Is it the one in s3.2.1 (IPv6 HE), which is referenced later in the
    
    section?
  14. Sean Turner: Comment [2012-07-17]:
    1) I support Adrian's discuss.
    
    
    
    2) I liked Pete's suggestions too.
    
    
    
    3) typos the secdir reviewer noted:
    
    
    
      gateway^1s => gateway's
    
      respectively => respectively
    
    
    
    5) s5: Any chance for specific references to were the BT-LE LL security and SMP
    
    are defined?  Is it part of the core?

draft-ietf-idr-rfc4893bis

  1. Benoit Claise: Comment [2012-07-11]:
    I would like to see the addition of section on the "manageability impact" of
    
    this change. Actually, the news are good in this case.
    
    
    
    1.  BGP-4 MIB module. This is taken care of (as far as I can tell), because the
    
    TC took care of the
    
    
    
    InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
    
        DISPLAY-HINT "d"
    
        STATUS       current
    
        DESCRIPTION
    
            "Represents an autonomous system number that identifies an
    
             Autonomous System (AS).  An AS is a set of routers under a
    
             single technical administration, using an interior gateway
    
             protocol and common metrics to route packets within the AS,
    
             and using an exterior gateway protocol to route packets to
    
             other ASes'.  IANA maintains the AS number space and has
    
             delegated large parts to the regional registries.
    
    
    
             Autonomous system numbers are currently limited to 16 bits
    
             (0..65535).  There is, however, work in progress to enlarge the
    
             autonomous system number space to 32 bits.  Therefore, this
    
             textual convention uses an Unsigned32 value without a
    
             range restriction in order to support a larger autonomous
    
             system number space."
    
        REFERENCE   "RFC 1771, RFC 1930"
    
        SYNTAX       Unsigned32
    
    
    
    Note: not sure many people are actually using this MIB module, but that's
    
    behind the point.
    
    
    
    2. IPFIX. This is taken care of, as
    
    http://www.iana.org/assignments/ipfix/ipfix.xml defines the max length. ( See
    
    bgpSourceAsNumber and bgpDestinationAsNumber ), and the Template Record defines
    
    the length, so 2 or 4 bytes.
    
    
    
    3. YANG. I don't believe there is anything BGP YANG module.
    
    
    
    Regards, Benoit.
  2. Adrian Farrel: Comment [2012-07-15]:
    I'm happy to support this document. I am in agreement with Barry that Appendix
    
    A is a disappointment. I think it would be helpful to boost this section with
    
    some more details.
  3. Barry Leiba: Comment [2012-07-11]:
    It's always helpful, when reviewing a "bis" document, to have a summary of
    
    changes.  So I was happy to see this, at the end of the Introduction:
    
    
    
       This document obsoletes RFC 4893, and a comparison with RFC 4893 is
    
       provided in Appendix A.
    
    
    
    Imagine my dismay, then, when I trotted down to Appendix A and found that it
    
    has but one, low-content sentence:
    
    
    
       This document includes several clarifications and editorial changes,
    
       and specifies the error handling for the new attributes.
    
    
    
    If that's all you had to say, you should have just put it into the Introduction
    
    in the first place.  Grumble.
    
    
    
    Happily, there's DIFF.  :-)
    
    
    
    And no, don't bother changing it now.  No objection, really, in any case.  Just
    
    me being slightly grumpy.
  4. Pete Resnick: Comment [2012-07-16]:
    Agree with Barry and Sean.
    
    
    
    I hope (expect) to see this document back on the IESG agenda soon moving to
    
    Internet Standard.
  5. Robert Sparks: Comment [2012-07-16]:
    I had the same question as Sean.
  6. Martin Stiemerling: Comment [2012-07-16]:
    I'm fine with this document, but I have to second Barry's comment about Appendix
    
    A.
  7. Sean Turner: Comment [2012-07-18]:
    Thanks for addressing my discuss.

draft-ietf-abfab-gss-eap

  1. Barry Leiba: Comment [2012-07-18]:
    Just one small thing about the IANA Considerations: The reference to "section
    
    4.1 of RFC 4121" makes it clear, but it would be useful if one detail of the
    
    registry in 7.2 were specified here... the "ID" field is two octets, specified
    
    in hex in big-endian order.  Having that bit here will make it easier for IANA
    
    to see that IDs have been specified correctly, without their having to go look
    
    in RFC 4121.
  2. Sean Turner: Comment [2012-07-18]:
    Only nits:
    
    
    
    1) abstract: expand GS2.
    
    
    
    2) s1: First sentence reads a little odd: The architecture describes an
    
    architecture.  Maybe the following is a little better:
    
    
    
    OLD:
    
    
    
     The ABFAB architecture [I-D.ietf-abfab-arch] describes an
    
     architecture for providing federated access management to
    
     …
    
    
    
    NEW:
    
    
    
     ABFAB [I-D.ietf-abfab-arch] describes an
    
     architecture for providing federated access management to
    
    
    
    3) s1: Maybe r/backend authentication server/backend authentication,
    
    authorization, and accounting (AAA) server that way AAA is expanded and
    
    introduced.
    
    
    
    4) s3.1: r/mechanism.The/mechanism. The
    
    
    
    5) s3.4: r/name.All/name. All
    
    
    
    6) s5: r/and body must be present/and body MUST be present
    
    
    
    7) s5.1: r/[RFC3961]is/[RFC3961] is
    
    
    
    8) s5.5.1 & s5.5.2 : r/required/REQUIRED
    
    
    
    9) s6: r/l bits of its input/L bits of its input  - ought to match the notation
    
    later which is uppercase L
    
    
    
    10) s10.2: There are some outdated references:
    
    
    
    == Outdated reference: A later version (-03) exists of
    
       draft-ietf-abfab-arch-02
    
    
    
    == Outdated reference: draft-ietf-krb-wg-gss-cb-hash-agility has been
    
       published as RFC 6542
    
    
    
    == Outdated reference: A later version (-06) exists of
    
       draft-ietf-radext-radius-extensions-05
    
    
    
    == Outdated reference: draft-ietf-radext-radsec has been published as RFC
    
       6614

draft-ietf-dnsext-dnssec-algo-imp-status

  1. Adrian Farrel: Comment [2012-07-18]:
    I am Abstaining on this document. I have no specific objection to its
    
    publication, but it  is so much not the document I would have written,
    
    and I struggle to see its value as currently presented.
    
    
    
    I was left wondering whether it is trying to do the wrong thing. Instead
    
    of tying to mandate what must or must not be implemented it would be
    
    more helpful to me to state the usage profile of each algorithm. This
    
    could then be traced to "dangerous to deploy" or "must be implemented
    
    if your implementation is to play a part in the deployment of this
    
    function."
    
    
    
    Anyway, here are some thoughts and comments that arose...
    
    
    
    ---
    
    
    
    Citing conformance to this document is confusing because nearly all of
    
    the information in the table in Section 2.2 indicates a degree of
    
    choice. Conformance can only be interpretted with respect to the "must"
    
    and "must not".
    
    
    
    ---
    
    
    
    To say that the "IANA registry for these algorithms ... lacks the
    
    implementation status of each algorithm"implies that this information
    
    should be recorded in the registry. It should not since that is not
    
    the purpose of the registry.
    
    
    
    How about...
    
    
    
       There is currently an IANA registry for these algorithms, but there
    
       is no record of the recommended implementation status of each
    
       algorithm.
    
    
    
    ---
    
    
    
    I think Section 1 should observe that it is the intention to issue
    
    replacements to this document when the implementation status of any
    
    algorithm changes and when new algorithms are introduced.
    
    
    
    ---
    
    
    
       This implementation status indication is only to be considered for
    
       implementation, not deployment or operations.
    
    
    
    I can't extract meaning from this! If something is marked "MUST NOT"
    
    implement, how can it possibly be deployed?
    
    
    
    ---
    
    
    
    Since this document makes no requests for IANA allocations and makes no
    
    changes to the existing registries, I see no reason for it to be listed
    
    in the registry. The IANA registry tracks code points, it is not a
    
    repository for documentation references.
    
    
    
    ---
    
    
    
    I can't square the statement in the Security Considerations section with
    
    the MUST NOT implement status assigned to RSAMD5. Maybe a reference is
    
    needed for the classification of RSAMD5 and that would keep Section 4
    
    honest.
  2. Stephen Farrell: Comment [2012-07-14]:
    
    I can't parse this: "It is believed that RSA/SHA-256 or
    
    RSA/SHA-512 algorithms will replace older algorithms (e.g.
    
    RSA/SHA-1) that have a perceived weakness or these
    
    recommended algorithms are seen in major deployments." I
    
    guess something's wrong but hard to know what, maybe
    
    s/or/or as/
  3. Brian Haberman: Comment [2012-07-13]:
    I agree with Barry that a discussion is needed as to why an IANA registry
    
    cannot capture the necessary information.
  4. Barry Leiba: Comment [2012-07-13]:
    Former DISCUSS, leaving it here for the record.
    
    
    
    In principle, I like the idea of preventing fragmentation of the documentation
    
    by keeping the Section 2.2 table in one place, and by always replacing the
    
    document that has it with another, in its entirety.
    
    
    
    Only... isn't that what the IANA registry is supposed to be for?  Why isn't
    
    that table just added to the IANA registry, and then maintained there?  Doesn't
    
    this document now require us to OBSOLETE this document and replace it every
    
    time we want to change the registry?
    
    
    
    ------------
    
    Update 1
    
    ------------
    
    I had no idea of the history of this, until Andrew pointed me at this:
    
    
    
       https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-fixes/ballot/
    
    
    
    I need to talk this over with Pete, Robert, and Russ, at least, on the
    
    telechat, and understand why we think we can't use the IANA registry the way
    
    registries are meant to be used.
    
    
    
    ------------
    
    Update 2
    
    ------------
    
    After more discussion with the chairs, here's what I understand...
    
    
    
    1. The conformance table needs to be normative, stable, and with maintained
    
    history.  It needs to be clear, when you say you conform as of [date X], what
    
    it is that you claimed to conform to.  You can conform to an RFC, because once
    
    it's published, you have a stable, immutable reference, and you can give the
    
    RFC number.  But if I asked you whether something conformed to the RRTYPEs
    
    registry, you'd have to ask "at what date?"  And IANA doesn't maintain a
    
    history.
    
    
    
    2. The conformance table is necessary in the first place because as things
    
    stand, you can say you "implement DNSSEC" when (for instance) you don't do
    
    NSEC3.  That's not going to be very useful, given that .com, .net, and .org are
    
    all using NSEC3.  We need a single document to which people can point and say,
    
    "We do it the way that says to."
    
    
    
    3. If it takes an RFC to update the registry, then any change to the table
    
    needs an RFC anyway.  Thus, I suppose there's no *harm* in just publishing the
    
    table in the RFC and not in the registry.  I do like that the basic table is
    
    still in the registry, and that this just extracts the conformance criteria
    
    into an RFC-maintained table.
    
    
    
    There's no point now, but it would have helped if, especially given the history
    
    of the earlier document, some of this information had been in the shepherd
    
    writeup.  But now that I understand the issues, I'm OK with this method of
    
    handling it.
  5. Pete Resnick: Discuss [2012-07-14]:
    Section 1:
    
    
    
       This implementation status indication is only to be considered for
    
       implementation, not deployment or operations.  Operators are free to
    
       deploy any digital signature algorithm available in implementations
    
       or algorithms chosen by local security policies.  This status is to
    
       measure compliance to this document only.
    
    
    
    I think the above paragraph is either wrong or meaningless. I don't know what
    
    it means to say that the implementation status is for implementation but not
    
    deployment. The reason that one "MUST IMPLEMENT" RSASHA1 is that an
    
    implementation will not interoperate with other DNSSEC deployments if it
    
    doesn't allow the use of RSASHA1. Similarly, the reason it is "RECOMMENDED TO
    
    IMPLEMENT" RSASHA1-NSEC3-SHA1 is that you won't interoperate in DNSSEC if you
    
    don't do it, but there are circumstances under which you might not use it. The
    
    reason you "MUST NOT IMPLEMENT" RSAMD5 is because it is a broken algorithm and
    
    use of it will cause damage. These are not about implementation; they are
    
    absolutely about interoperation. Operators *are* free to deploy anything they
    
    like, but that's because there are no protocol police and you are free to
    
    ignore the considered consensus of the IETF. But the considered consensus of
    
    the IETF is that these are protocol requirements to allow for interoperation.
    
    The IETF is *not* supposed to be writing compliance documents. Please strike
    
    the paragraph in it's entirety. See next bit on 2119 keywords for more on this.
    
    
    
    Section 1.1:
    
    
    
    2119 keywords are used as part of the implementation status. This is awfully
    
    confusing because you lose the meaning of the 2119. Please (a) title case the
    
    implementations status throughout Section 2 by changing, e.g., MUST IMPLEMENT
    
    to "Must Implement", etc. and then (b) define the terms in section 1.1:
    
    
    
       The implementation statuses used in this document are defined as follows:
    
    
    
       - "Must Implement" means that the algorithm MUST be used in order
    
         to interoperate with other implementations on the Internet.
    
    
    
       - "Must Not Implement" means that the algorithm MUST NOT be used so
    
         as to prevent the compromise of the DNS data; the algorithm has
    
         known weaknesses and is not considered safe to use anymore.
    
    
    
       - "Recommended To Implement" means that the algorithm SHOULD be
    
         used in order to interoperate with other implementations on the
    
         Internet, though there may be exist valid reasons in particular
    
         circumstances not to do so. An implementer must understand and
    
         weigh the full implications of choosing not to implement this
    
         particular algorithm.
    
    
    
       - "Optional" means that the algorithm MAY be implemented, but that
    
         all implementations MUST be prepared to interoperate with
    
         implementations that do or do not implement this algorithm.
    
    
    
    Section 2.2:
    
    
    
       Their implementation (or lack thereof) therefore cannot be included
    
       when judging compliance to this document.
    
    
    
    Strike this sentence. Again, it is meaningless in the context of an IETF
    
    document. This document should only talk about interoperability requirements.
    
    
    
    With regard to the status and title of this document:
    
    
    
    I believe in the normal course of events, each time a new document with a list
    
    of statuses is published, we will get implementation experience with the
    
    statuses to determine if they are correct. When we do, we can advance the
    
    document to indicate that, yes, we are sure that implementations have now taken
    
    up this new document and it is considered the standard way to implement. I
    
    therefore think that this document should be standards track instead of BCP.
    
    Indeed, the title of "Applicability Statement" I think is exactly right, and
    
    it's using the term as 2026 envisioned, which puts this on the standards track.
    
    
    
    If there is for some reason not consensus to move this to the standards track,
    
    I think a change of title and abstract are in order. "Applicability Statement"
    
    gets used in an odd way in the IETF (and in 2026 in particular), and I think
    
    using it for a BCP will add to our overall confusion. But I still believe that
    
    this is appropriate to the standards track.
  6. Pete Resnick: Comment [2012-07-14]:
    Section 1:
    
    
    
    Please also add a paragraph to indicate what's coming in 2.3:
    
    
    
       Since one of the motivations of this document is to keep a single
    
       up-to-date list of implementations statuses, this document also
    
       establishes a procedure for updates to this document in the future.
    
    
    
    Section 2.2:
    
    
    
    Please add the sentence, "Any registered algorithm not listed in the table
    
    above has the status "Optional"."
    
    
    
    Section 2.3:
    
    
    
       Algorithms entered into the registry using that procedure are to be
    
       considered OPTIONAL for implementation purposes.  Specifications that
    
       follow this path do not need to obsolete or update this document.
    
    
    
    I think the above got things around backwards. That is, we don't need this
    
    document (and obsoleting it) to be tied so directly to registration. We want to
    
    say that any registered algorithm that does not appear in this document is, by
    
    definition, "Optional". In fact, you can remove the specific algorithms in the
    
    "Optional" column in 2.2 and simply say, "Any IANA registered DNS Algorithm not
    
    otherwise listed." If you do that, this entire section can be:
    
    
    
    2.3 Statuses For New Algorithms and Updating Existing Statuses
    
    
    
       This document establishes a procedure for additions and changes to
    
       the list of algorithm implementation statuses. In particular, it has
    
       turned out to be desirable for implementations to be able to point to
    
       a single document that describes the implementation statuses of all
    
       algorithms that they might use. Therefore, when a new algorithm is
    
       registered that has an implementation status other than "Optional",
    
       this document shall be obsoleted by a new similar document, adding
    
       the new algorithm to the table in section 2.2. Similarly, if any
    
       algorithm currently listed in the table in 2.2 changes status, this
    
       document shall be obsoleted by a new similar document and the table
    
       in 2.2 shall be fully replaced. In this way, there is always one
    
       authoritative document with the list of implementation statuses.
    
    
    
    I understand that you might want the "shall"s in the above to be "SHALL"s. I
    
    don't think it is necessary, and I think it's not a proper use of 2119
    
    keywords, other IETF practice notwithstanding.
  7. Robert Sparks: Comment [2012-07-18]:
    I support Pete's suggestion to make this standards track.
  8. Martin Stiemerling: Comment [2012-07-16]:
    A nit:
    
    Section 2.1., paragraph 2:
    
    
    
    >    Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and
    
    >    ECDSAP384SHA384) are algorithms that may see widespread use due to
    
    >    the precieved similar level of security offered with smaller key size
    
    >    compared to the key sizes of algorithms such as RSA.
    
    
    
      s/precieved/perceived/

draft-ietf-dnsext-dnssec-registry-update

  1. Adrian Farrel: Comment [2012-07-15]:
    It is entirely unimportant, but I think most if not all references could be
    
    Informational rather than Normative.
  2. Barry Leiba: Comment [2012-07-09]:
    A nit: you've misspelled "Hellman" (as "Hellmen") in the Introduction.

draft-ietf-appsawg-received-state

  1. (none)

draft-ietf-pkix-caa

  1. Ralph Droms: Comment [2012-07-18]:
    I agree with the points raised by Barry and Russ.
    
    
    
    Building on one of Stephen's comments: are the requirements
    
    for archiving DNS transactions regarding CAA based on
    
    actual audit requirements or are they speculative?  Why would
    
    this document include those specific requirements instead of
    
    a more general statement about "meeting audit requirements"
    
    from whatever audit process is employed?
    
    
    
    Minor editorial suggestion: in section 3, I think you should cite
    
    more than just RFC 1035 as references for CNAME and DNAME
    
    processing.
  2. Adrian Farrel: Comment [2012-07-19]:
    I have no objection to the publication of this document and only a
    
    couple of (well, four) trivial obeservations.
    
    
    
    ---
    
    
    
    Would be nice to add just a couple of words to what is otherwise a good
    
    Abstract to say what this document actually does.
    
    
    
    ---
    
    
    
    The RFC editor will probably want to work with you to move the
    
    Introduction to be the first section in the document.
    
    
    
    ---
    
    
    
    I don't think Section 6.3 should be a subsection of Section 6!
    
    
    
    ---
    
    
    
    Are you sure that you dn't want an IANA registry for the Flags field
    
    defined in Section 4.1?
  3. Stephen Farrell: Comment [2012-07-16]:
    
    - I agree with Russ' discuss - the "tree-walking vs. not"
    
    disussion needs to be worked through before this is ready.  Is
    
    the wildcard cert part of the gen-art review part of Russ'
    
    discuss? I think the authors also said they'd fix that.
    
    
    
    - Overall comment: I think this is a fine function to offer, but
    
    this draft is IMO over complicated and could be a lot simpler.
    
    Nonetheless, I think it can be used as-is, so going forward is
    
    better than holding it up, modulo Russ' discuss.
    
    
    
    - A suggested addition for the abstract: "CAA Resource Records
    
    are intended for consumption by CAs and not by other entities
    
    involved in public key infrastrucures." I think it'd help the
    
    reader to get that from the abstract.  I don't care how that's
    
    worded but the above might work.
    
    
    
    - Section 1.2: (This was nearly a discuss but I expect it'll be
    
    sorted as part of Russ' discuss.) The definition of Public
    
    Delegation Point is imprecise.  I realise any precise definition
    
    is controversial but you include it in the tree-walking
    
    algorithm here and different interpretations could lead to
    
    unexpected non-issuance without any attack. I think that at
    
    least needs to be noted.
    
    
    
    - Section 2: While you do define the term "Certificate
    
    Evaluator" properly, I don't personally like the term, as I
    
    think its too easily confused with RP. However, that's just me,
    
    so this isn't discuss-worthy, but I nonetheless think it'd be
    
    worth the following change in the last para before 2.1: s/CAA
    
    Records MAY be used by Certificate Evaluators/CAA Records MAY be
    
    used by Certificate Evaluators (who are, by definition, not
    
    Relying Parties)/
    
    
    
    - You probably should say that "1" means "set" for Issuer
    
    Critical and "0" means unset.
    
    
    
    - Using "MUST NOT" as part of an example seems wrong since 2119
    
    language would be better avoided there.  I'd suggest s/The
    
    following example informs CAs that certificates MUST NOT/The
    
    following example informs CAs that certificates ought not/
    
    
    
    - Be good to provide a reference so people can understand the
    
    zone file syntax used in the examples.
    
    
    
    - The first example in 2.1 refers to this being at the public
    
    delegation point, but you've not said anything about that so
    
    far, other than the definition.
    
    
    
    - Section 3, 1st para, might be better to s/the CA/ a compliant
    
    CA/ in the last sentence of this para.
    
    
    
    - Last para before 3.1 says "unless the certificate conforms"
    
    but I didn't think you were defining conformance for
    
    certificates, maybe s/certificate/Issuer/ here?
    
    
    
    - DNSSEC can demonstrate non-existence of a domain.  If an
    
    Issuer receives a request for foo.bar.example.com and DNSSEC
    
    shows there's no such domain then oughtn't that result in
    
    non-issuance for a compliant CA? Worth a mention here? (I'd say
    
    maybe.)
    
    
    
    - I personally doubt that use of DNSSEC gives an issuer a
    
    non-repudiable proof. I'd delete the phrase.
    
    
    
    - Is the ABNF for 'parameter' correct? Looks wrong to me.
    
    
    
    - I think this bit of 5.2 is badly stated: " A CA MUST mitigate
    
    this risk by employing DNSSEC verification whenever possible and
    
    rejecting certificate requests in any case where it is not
    
    possible to verify the non-existence or contents of a relevant
    
    CAA record." I think you want to say that "a compliant CA MUST
    
    implement DNSSEC validation" but I'm not sure you can say
    
    anything about rejecting requests really.
    
    
    
    - 6.1, 1st para is missing a ")" before "deleted."
    
    
    
    - 6.2, I don't get why "auth," "path" and "policy" are reserved
    
    without any further mention.
    
    
    
    - 6.2, the public CA business can be competitive. If you could
    
    specify more about when the expert is supposed to say yes or no,
    
    that'd be good, especially if (as is probably likely) the expert
    
    is liable to end up being employed by some CA operator.
  4. Brian Haberman: Discuss [2012-07-18]:
    Many of these points come out of the DNS Directorate review performed by Andrew
    
    Sullivan...
    
    
    
    1. The definition of "Public Delegation Point" is incomplete given previous
    
    definitions of the same thing, albeit by different names.  The suggestion to
    
    address this is to add something to the definition like : "Also known as public
    
    suffix, effective TLD, and public domain".  It would also be good to strike the
    
    term "suffix" from the definition.  More importantly, this definition does not
    
    seem to agree with the text in section 2.1.  In 2.1, the draft says "Since the
    
    policy is published at the Public Delegation Point, the policy applies to all
    
    subordinate domains..." The definition of Public Delegation Point means that
    
    "com" is the delegation point ("under which DNS names are delegated": "com"
    
    does the delegation).  Second, this seems to suggest that the policy flows
    
    top-down and constrains subordinate names, but that's not what's in section 3.
    
    
    
    2. The definition of "Resource Record" has several issues.  First, it does not
    
    incorporate the fact that RRs come in sets. Given that, this definition is
    
    stretching things to the point of being misleading. A proposed fix to the
    
    definition is : "A particular entry in the DNS including the owner name, class,
    
    type, time to live, and data, as defined in [RFC1035] and [RFC2181].  Resource
    
    records come in sets identified by the owner name, class, and type.  The time
    
    to live on all RRs is always the same.  The data may be different among RRs in
    
    an RRset."
    
    
    
    3. Section 2.1 gives this example for specifying additional information:
    
    
    
       $ORIGIN example.com
    
       .       CAA 0 issue "ca.example.net; account=230123"
    
    
    
    And the text following it states : "The syntax and semantics of such parameters
    
    is left to site policy and is outside the scope of this document."
    
    
    
    If the above is true, how does a consumer of this information know that the ";"
    
    is a separation character?  If this document is defining the "issue" tag,
    
    shouldn't have to specify the syntax?
    
    
    
    4. It appears that the Extended Issuer Authorization Set notation (section 3)
    
    needs some work.  The first issue is the one raised in the Gen-ART review about
    
    tree-climbing.  The other is the implicit constraint that this notation puts on
    
    subordinate names.  If I control a domain with a published CAA record and
    
    delegate a sub-domain to someone, they are stuck using the CA of my choice
    
    unless they publish their own CAA.
    
    
    
    5. Section 3 also states the following:
    
    
    
       The DNS defines the CNAME and DNAME mechanisms for specifying domain
    
       name aliases.  The canonical name of a DNS name is the name that
    
       results from performing all DNS alias operations.  An issuer MUST
    
       perform CNAME and DNAME processing as defined in the DNS
    
       specifications [RFC1035] to resolve CAA records.
    
    
    
    In combination with the tree-climbing issue, this is going to be problematic. 
    
    Suppose we have :
    
    
    
        example.net DNAME example.com
    
        example.net CAA [$x]
    
        foo.example.com CAA [$y]
    
    
    
    If someone requests a certificate for bar.foo.example.net, does the CAA at
    
    example.net rule, or the CAA at foo.example.com?  It appears that the one at
    
    foo.example.com would be chosen because the alias resolution appears to be
    
    performed before anything else.  Is that the intent?
  5. Brian Haberman: Comment [2012-07-18]:
    1. The issue of tree-walking (mentioned in Russ' position) was also identified
    
    as an issue by Andrew Sullivan during his DNS Directorate review.  It would be
    
    good to get that issue resolved.
    
    
    
    2. The use of ASCII encoding for the tags is confusing.  It would appear that
    
    the tags could be a bit field given their usage.
    
    
    
    3. The terms "Canonical Domain Name" and "Canonical Domain Name Value" are not
    
    used anywhere in the draft even though they are defined.  I would suggest
    
    striking them from section 1.2.  If the definitions are kept, and properly used
    
    in the document, I would suggest expanding the definition of Canonical Domain
    
    Name to include discussion of DNAME aliases.
    
    
    
    4. The definition of Domain is confusing given its use of the term "resources".
    
     These resources cannot be resource records, so what are they?  Andrew also
    
    pointed out that this definition gets even more confusing given the use of the
    
    "domain" in the ABNF in section 4.2.
    
    
    
    5. The definition of "Domain Name" should reference RFC 1034, rather than RFC
    
    1035.
    
    
    
    6. The definition of "Domain Name System" should reference STD13.  STD13 refers
    
    to both RFC 1034 and RFC 1035.
    
    
    
    7. The definition of "DNS Security" should reference RFCs 4033, 4034, 4035, and
    
    5155.
    
    
    
    8. The ABNF in 4.2 constrains domains to the hostname/LDH syntax. The draft
    
    should make an explicit statement about that limitation since the draft
    
    suggests that you can use CAA for "domain names", but not for domain names made
    
    up entirely of LDH-labels.
    
    
    
    9. Does section 4.3 constrain iodef URLs to the mailto and http[s] schemes only?
    
    
    
    10. Section 5.3 suggests that complete failure to get an answer for CAA queries
    
    for a name results in the issuer refusing to issue a certificate.  This could
    
    be stated more directly.
  6. Russ Housley: Discuss [2012-07-14]:
    
      The Gen-ART Review by Richard Barnes on 6-July-2012 started a
    
      discussion.  Some points have been resolved, and others have not.
    
      Looking in the entry associated with the public delegation point
    
      as opposed to tree walking has not reached closure.  When the
    
      discussion does reach closure, I believe the document should be
    
      updated to capture the agreed points from the discussion.
  7. Barry Leiba: Discuss [2012-07-18]:
    [Update: DNS Directorate review has arrived, and Brian is handling the issues
    
    from that. I'm removing that from my DISCUSS.]
    
    
    
    One point remaining:
    
    
    
    In section 6.2:
    
       Addition of tag identifiers requires a public specification and
    
       expert review as set out in [RFC6195]
    
    
    
    RFC 6195 isn't the usual reference for IANA registration policies (we usually
    
    use RFC 5226).  Using another is fine if it's clear what you mean, but I don't
    
    see that it is: What section of 6195 defines the expert review policy you're
    
    talking about?  The phrase "Expert Review" (capitalized, as it turns out)
    
    appears twice in Section 3.1.1, in reference to DNS RRTYPE allocations, and
    
    it's quite specific to DNS RRTYPEs -- it requires posting a message with a
    
    specific template to dnsext@ietf.org, for example, and it gives guidelines to
    
    the expert (in Section 3.1.2) that don't seem to be applicable here (they're
    
    also specific to RRTYPEs).
    
    
    
    Please clarify what the policy is, exactly where it's documented, and what the
    
    designated expert is supposed to consider in her review.
  8. Pete Resnick: Comment [2012-07-18]:
       label = 1* (ALPHA / DIGIT / "-" )
    
    
    
    If you're trying to conform to host syntax, I wish you would reference it from
    
    another RFC. In any event, the above is not correct. Try:
    
    
    
       label = (ALPHA / DIGIT) *(["-"] (ALPHA / DIGIT))
  9. Robert Sparks: Comment [2012-07-18]:
    Should automata processing a record with the iodef property do any sort of
    
    validation of the URI it finds there before using it? (The examples point into
    
    the same domain, but that's not a restriction, right?).
    
    
    
    The draft says "Web Service" a few times, sometimes capitalized that way, when
    
    pointing to RFC6546. This could lead to confusion with WSDL/SOAP which RFC6546
    
    does not use.

draft-sandlund-rfc4996bis

  1. Stewart Bryant: Comment [2012-07-19]:
    As Sean says it would be useful to have the differences more visible at the
    
    front of the document. A forward reference in the Introduction would in my view
    
    be an acceptable way to achieve this.
  2. Stephen Farrell: Comment [2012-07-16]:
    
    - The new text in the intro, 2nd para, says something "must
    
    be supported." Is that a 2119 MUST? If so, does it need to be
    
    elsewhere as well if you're avoiding 2119 terms in the intro?
    
    I didn't spot that when looking at the diff vs. 4996, so
    
    where is the relevant 2119 language for that new(?) "must"?
    
    
    
    - In the same intro text it might be better to s/may
    
    not/cannot/ just to avoid 2119-like terms.
    
    
    
    - In section 3, 2nd last para, you've taken out compression
    
    of NULL-encrypted ESP headers (rfc 4303). Wouldn't it be nice
    
    to call that out explicitly so that someone updating code
    
    might more easily spot it without having to diff vs. RFC
    
    4996? Similar comment on the list on p22 and p35. I realise
    
    you point this out in 9.1, but it might be nice to also
    
    note it in the places from which its been removed. (Note
    
    that this is just a "nice-to-have" kind of comment, I've
    
    no problem at all if you'd rather not change.)
  3. Russ Housley: Discuss [2012-07-17]:
    
      The issue below is the same as the one raised in the Gen-ART Review
    
      by Joel Halpern on 16-July-2012.
    
    
    
      Section 5.2.2.2 on negative acknowledgments includes the following:
    
      >
    
      > ... unless it has confidence that information sent after the packet
    
      > being acknowledged already provides a suitable response ...
    
      >
    
      This deals with a specific response to the NACK, it is unclear what
    
      constitutes confidence.  Other places in this document that refer to
    
      gaining confidence provide specific descriptions of how it is gained.
    
      The primary methods for gaining confidence are receiving acks or
    
      sufficient transmissions.  If all that is meant here is sufficient
    
      transmissions, please say so.
  4. Sean Turner: Comment [2012-07-17]:
    I think it would be better if the changes were nearer the front of the draft. 
    
    I suggest moving s9 to s1.1 (again this is only a suggestion).

draft-camarillo-rai-media-policy-dataset

  1. Stephen Farrell: Discuss [2012-07-16]:
    
    This discuss & comment probably looks worse than it is.
    
    I'd hope it'll all be easily sorted.
    
    
    
    (1) 3.3.1, visibility attribute says if UA is "permitted" to
    
    show the user stuff - yuk! Shouldn't that be the UA developer's
    
    choice? I'd say s/permitted/advised/ would be fine. I think the
    
    "SHOULD NOT display" here is just inappropriate as its nothing
    
    to do with interoperability and is just silly, since people will
    
    make tools to show that stuff if you try hide it. (I realise
    
    that my suggested change conflicts with Barry's suggestion for
    
    fixing the issue in his comment, but I think the way to fix the
    
    problem we've both identified is to get rid of the pretence that
    
    you can hide stuff you send the UA.)
    
    
    
    (2) 4.1, Why MUST a UA include the remote-host-port in all
    
    session-info documents? That seems a bit privacy unfriendly to
    
    say the least. I can see that it might be needed sometimes, but
    
    why all the time, and why can't the UA just not tell the policy
    
    server who its calling?  (Same comment about elsewhere where the
    
    same information is a MUST.)
    
    
    
    (3) I think section 9 (or somewhere else, I don't care) needs to
    
    call out when TLS is needed, that is, when TLS MUST be used and
    
    how. (I'm only asking about TLS since S/MIME usage here is
    
    apparently mythical.) In particular, I think you need to say
    
    when a UA MUST authenticate a policy server or source of policy
    
    information, and how it can check that its getting the right
    
    policy from the right source or giving stuff to the right
    
    server.  I think sending out remote host/port information and
    
    accepting intermediary information in particular would seem to
    
    call for use of TLS with server-authentication, though there may
    
    be additional cases too.  I would imagine that you'd need to
    
    check that the policy-server element (if present) matches the
    
    TLS server cert somehow. If the policy-server is absent, or when
    
    a UA is sending sensitive information, then I don't know how
    
    you'd know you're giving/getting the right policy info.
    
    Finally, do merge operations need a web-origin like concept?
    
    Without that, it'd seem like anywhere I visit might be able to
    
    corrupt my UA's "policy state" (to invent a term that might be
    
    missing.)
    
    
    
    Sorry to lump a few different things together in point (3); I
    
    suspect that we'll tease them apart in the discussion, but I'm
    
    not sure right now how to do that properly.
  2. Stephen Farrell: Comment [2012-07-16]:
    
    - 3.3.3: What is the allowed precision for the 'q' attribute?
    
    Does a UA have to be able to properly handle
    
    0.0000000000000000000000000000000000000000001?
    
    
    
    - 3.3.4: Is the 'media-type' attribute restricted to the top
    
    level types?  If so, maybe say so. (From later, it appears to be
    
    just the top level type.)
    
    
    
    - 3.3.4: Would 'media-type' == "multipart" or "application" or
    
    "message" make sense? If not, maybe say so. If so, what'd those
    
    mean? What if a new top level type is finally defined?  What is
    
    a UA supposed to to with that?
    
    
    
    - 3.3.6: Does the MUST NOT for the value "no" need a bit more
    
    context? E.g. "MUST NOT establish the media stream when this
    
    policy is relevant" or something? Is there a danger that a UA
    
    might otherwise remember this setting for too long, e.g. if it
    
    roams?
    
    
    
    - 5.1, What is the logical AND of media-intermediaries? I don't
    
    get that. (Or can it happen? Maybe I got confused here:-)
    
    
    
    - 5.7, Why call out the "visibility" attribute here? Trying to
    
    keep allowed-ports secret (if that's the goal) this way would be
    
    silly - anyone can probe.
    
    
    
    - 6.3, Is 1 "kilobit per second" 1024 bits per second? Might be
    
    worth saying so explicitly in case higher speeds cause
    
    confusion, e.g. "mega bit" might be taken as 1024kbps or
    
    1,000,000bps.
    
    
    
    - 6.3, Why bother try hiding the max-bw? The only real effect I
    
    could see would be an increase in the number of conspiracy
    
    theories;-)
    
    
    
    - The last two comments also apply for 6.4 & 6.5.
    
    
    
    - 6.7.1, Is this for anything other than debug? If so, what?
    
    (Its not stated, and brings up questions in my little head about
    
    authenticating policy servers.)
    
    
    
    - 6.7.4, can a request-URI element contain PII? If so, how would
    
    that be protected?
    
    
    
    - 7.1, the policy-server URI has no scheme. What's up there?
    
    (The webfinger discussion on apps-discuss and the acct: URI
    
    scheme proposed might be of use here?)
    
    
    
    - Section 9, maybe s/privacy/confidentiality/ in 1st para, since
    
    I think that's what you mean.
    
    
    
    - Section 9: section 4.1 calls for mandatory inclusion of the
    
    local & remote host/port and perhaps creates a new attack - try
    
    get a UA to send me session-info documents to see who they're
    
    talking to?  I think that'd warrant a mention here to tell UA
    
    developers to be cautious in sending out such private
    
    information. (And here I do mean privacy-sensitive and not
    
    requiring confidentiality:-)
    
    
    
    - Section 9, Section 4.4's media intermediaries also seems to
    
    increase the attack surface. Doesn't that warrant a mention?
    
    Maybe say that UAs need to be cautious here in accepting
    
    instructions about which intermediaries to use?
  3. Barry Leiba: Discuss [2012-07-14]:
    [Update: I neglected to take into account the new media-types procedures
    
    document we just approved.  The media-type registration request has been done
    
    correctly, and IESG approval of this RFC is adequate to have IANA make the
    
    registration.  My apology for this erroneous part of the DISCUSS, which point
    
    is now cleared.]
    
    
    
    -- Section 3.3.4 --
    
       The value of the 'media-type' attribute MUST
    
       be the media type, such as 'audio', 'video', 'text', or
    
       'application'.
    
    
    
    It looks like this value is meant to be one of the registered top-level media
    
    types in the Media Types Registry, yes?  If so, please say that.  As it is, it
    
    seems underspecified: you give four examples, but I might be allowed to put
    
    "font" in there, which we've batted around as a possible new top-level media
    
    type that doesn't yet exist... I'm not sure.
    
    
    
    I think it's unlikely that you want to allow unregistered top-level types.
    
    
    
    Maybe this?:
    
    NEW
    
       The value of the 'media-type' attribute is the media type of
    
       the stream, and MUST be a (top-level) Media Type that is
    
       registered in the Media Types IANA registry.  Examples are
    
       'audio', 'video', 'text', and 'application'.
    
    
    
    This also applies to the <media-type> element.
    
    
    
    For the <media-type-subtype> element, you say this:
    
    -- Section 6.2.1 --
    
       The <media-type-subtype> element contains a media type and subtype
    
       that identifies a codec.  The value of this element MUST be a media
    
       type and subtype [RFC4855] separated by a "/" (e.g., audio/PCMA,
    
       audio/G726-16 [RFC4856] or video/H263 [RFC4629]).
    
    
    
    By using the RFC4855 citation, are you really saying this?:
    
    NEW
    
       The <media-type-subtype> element contains a media type and subtype
    
       that identifies a codec.  The value of this element MUST be a media
    
       type and subtype that is registered as an RTP Payload Type [RFC4855],
    
       separated by a "/" (e.g., audio/PCMA, audio/G726-16 [RFC4856] or
    
       video/H263 [RFC4629]).
    
    
    
    (Of course, you might want to allow for unregistered subtypes, so I'm not sure
    
    exactly what you want.  What I am sure about is that the document needs to be
    
    clear about where these primarily come from, and when it's appropriate to
    
    stray.)
  4. Barry Leiba: Comment [2012-07-13]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- Section 3.3.1 --
    
          hidden: Specifies that the user agent SHOULD NOT display the
    
          property value.
    
    
    
    SHOULD NOT, really?  If an administrator wants to hide this, she can't rely on
    
    its being hidden?  Why isn't this MUST NOT?  Or maybe what you want is this, to
    
    go with the subsequent sentence?: NEW
    
          hidden: Specifies that the user agent MUST NOT display the
    
          property value to ordinary users.
    
    
    
    ========
    
    Other comments; no need to respond to these.  Really, I'm just grumbling.
    
    
    
    I have to grumble about the shepherd writeup for this:
    
    
    
      The document, in particular the registration of the media type/subtype
    
      media-policy-dataset+xml, has been reviewed on the ietf-types mailing list.
    
    
    
    It has not "been reviewed" there at all.  A request for review was posted, and
    
    there were no responses.  That's not a bad thing, but it should have been
    
    explained that way, not presented as a review.
    
    
    
    I also have to grumble about the IANA Considerations section, which does not
    
    clearly specify what registries it's asking for things to be put into.  IANA
    
    figured it out, so I'm not asking for any changes here.  Just for future:
    
    please be clear about this, so IANA never has to guess (and will not,
    
    therefore, ever guess wrong).
  5. Pete Resnick: Comment [2012-07-18]:
    Section 4.3.1:
    
    
    
       The <stream> element MUST contain one <media-type> element, one or
    
       more <codec> elements and one <local-host-port> element.  The
    
       <stream> element MAY contain one <remote-host-port> element.
    
    
    
    That last MAY strikes me as ambiguous. Did you mean MUST contain zero or one
    
    <remote-host-port> elements?
    
    
    
    Section 4.4:
    
    
    
       Multiple <media-intermediaries> elements MAY only be present in a
    
       container if each applies to a different set of streams (e.g., one
    
       <media-intermediaries> element for incoming and one for outgoing
    
       streams).
    
    
    
    Another ambiguous MAY. Instead can I suggest:
    
    
    
       Multiple <media-intermediaries> elements MUST NOT be present in a
    
       container unless each applies to a different set of streams (e.g.,
    
       one <media-intermediaries> element for incoming and one for
    
       outgoing streams).
    
    
    
    See also 5.3, 5.4, 5.6. "MAY only" is a bad construct.
    
    
    
    Section 6.7.5:
    
    
    
       The use of this token is described in the Framework for SIP
    
       Session Policies [I-D.ietf-sip-session-policy-framework].  Since the
    
       token value must be encodable as a SIP URI parameter value, it MUST
    
       consist of ASCII characters, that is, in the range U+0020 to U+007E.
    
    
    
    Either strike ", that is, ", or change "ASCII characters" to "visible ASCII
    
    characters plus space". And you do want to allow space? And not TAB? And not
    
    other things that can be %encoded? I'm not clear on the requirement here. For
    
    the record, "token" is not defined this way in 3261. Just looking for
    
    clarification.
  6. Sean Turner: Discuss [2012-07-19]:
    Hmm so under what circumstances would I not wan the protocol used to distribute
    
    session info and session policy doucments to not ensure authentication,
    
    privacy, and message integrity?
    
    
    
    Is the gist of the must for shared-secret that you consider that to be the only
    
    item that MUST be kept private?  Not user id too?
  7. Sean Turner: Comment [2012-07-19]:
    s3.3: Says the recipient MUST ignore the attribute.  Is the recipient the user
    
    agent or the user? I suspect it's the former - shouldn't it say that instead?
    
    
    
    s3.3.1: Is there an override on this?  I'm thinking I'm with Stephen here.  An
    
    additional reason is that normally display stuff (my technical term) is
    
    out-of-scope - isn't it?
    
    
    
    s4.2: optional is redundant: r/MAY contain the optional/MAY contain the

draft-farrell-decade-ni

  1. Stewart Bryant: Comment [2012-07-19]:
    Wes makes an interesting point about whether this should be experimental.
    
    
    
    If ever there were a good case for embedded mp4 in an RFC it is the nih example
    
    in section 8.3
  2. Wesley Eddy: Comment [2012-07-17]:
    I don't have any technical problem with this document.
    
    
    
    I doubt that it needs to go on the standards track though; it smells
    
    experimental to me.  There are lots of potential uses, but who is using it?
    
    
    
    There's a note that it's similar to magnet URIs, but no mention of why it's
    
    better.  Since magnet is in widespread use, this seems important to give the
    
    analysis for, otherwise we should just be putting magnet on the standards track.
  3. Adrian Farrel: Comment [2012-07-15]:
    I have no objection to the publication of this document. Here are a couple of
    
    minor thoughts you might consider before publication...
    
    
    
    ---
    
    
    
    It would be helpful if the Abstract briefly stated the motivation for
    
    this work.
    
    
    
    ---
    
    
    
    In Section 2
    
    
    
       Truncated hashes MAY be supported if needed.
    
    
    
    That is a bit confusing! "If needed" implies there could be cases where
    
    there is a need - "need" sounds like "MUST". If you stick with "MAY"
    
    then you will need to explain what happens when there is a "need" and
    
    truncated hashes are not supported.
    
    
    
    Alternatively, you need to scope when truncated hashes are needed and
    
    direct implementations to support truncated hashes (MUST) when they are
    
    operating in that environment.
    
    
    
    ---
    
    
    
    Section 7
    
    
    
    The redefinition of "nih" merits a reference to RFC 5513
  4. Pete Resnick: Discuss [2012-07-19]:
    I do not think this document has a reasonable URI registration and I would like
    
    more information from the Expert Reviewer of how this passed muster. The
    
    current registration template says:
    
    
    
    Applications/protocols that use this URI scheme name: General
    
       applicability.
    
    
    
    I do not see how that satisfies the requirements of a URI registration.
    
    Moreover, I think this is indicative of a deeper problem: I cannot find an
    
    example of a URI that works the way ni: URI seems to work. The document
    
    provides no resolution mechanism for these URIs. The resolution mechanism seems
    
    to be "this will be resolved however your local implementation decides that
    
    they are to be resolved." This is not interoperable. And as far as I can tell,
    
    this is a big architectural shift from the normal use case of URIs. I think
    
    this needs pretty serious discussion.
  5. Robert Sparks: Comment [2012-07-17]:
    Consider explicitly calling out that padding (=) is not included when
    
    base64url-ing.
  6. Sean Turner: Discuss [2012-07-17]:
    In s2 you point out that sha-256-32 is useful for naming but not so much for
    
    security.  When values are included in the hash algorithm registry should a
    
    column be included to indicate whether they are useful for security and naming
    
    or just naming?  If not in the registry then in the document in which they are
    
    defined?
  7. Sean Turner: Comment [2012-07-17]:
    1) r/sha-256 with SHA-26 to match 180-3 ;)
    
    
    
    2) s3: r/Required/REQUIRED and Optional/OPTIONAL - assuming these are supposed
    
    to be 2119 words
    
    
    
    3) s4: did you mean to reference 2818 for HTTPS or 2617?
    
    
    
    4) s6: Should probably add that Res fields SHOULD be ignore upon receipt too.
    
    
    
    5) s7: liked the joke
    
    
    
    6) s7: OPTIONALLY isn't a 2119 keyword.
    
    
    
    7) s9: Shame we can't reuse
    
    https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml but I guess IANA registries are cheap.
    
    
    
    8) s9.4: Is the sentence about before approving the request only about
    
    deprecating or is that in general?  I'd love to give some advice to the initial
    
    expert along the lines of if anybody tries to register md2/4/5 then they can
    
    only be used for naming?  Maybe add references to 6149-6151?
    
    
    
    9) s12.1: Any reason you can't point to 180-3?

draft-ietf-karp-threats-reqs

  1. Adrian Farrel: Comment [2012-07-19]:
    I am pleased to support the publication of this document.
    
    
    
    Requirement 20 in Section 4 seems to be the only one without an RFC 2119
    
    word.
    
    
    
    Think this should be:
    
    
    
            Thus proposed solutions SHOULD be evaluated carefully with
  2. Brian Haberman: Comment [2012-07-13]:
    - Section 1.1
    
    
    
    s/assymetric/asymmetric/
    
    
    
    - Section 2.1
    
    
    
    * I agree with Barry that the document should not inter-change confidentiality
    
    and privacy.  They are different components and can be accomplished in vastly
    
    different ways.
    
    
    
    - Section 2.3
    
    
    
    * Does backwards compatibility need to be considered?  Or is it being implied
    
    within the incremental deployment discussion?
    
    
    
    - Section 4
    
    
    
    * It may be the way I am reading them, but requirements 21 and 22 seem to be
    
    contradictory.  Requirement 21 says "if you can, centralize some features to
    
    reduce the work load on all routers".  On the other hand, requirement 22 says
    
    "don't build in any external dependencies".
  3. Barry Leiba: Comment [2012-07-12]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    -- Section 2.1 --
    
       Three basic services may be employed in order to secure any piece of
    
       data as it is transmitted over the wire: confidentiality,
    
       authenticity, or integrity.
    
    
    
    You're not talking about *employing* these to secure anything; they're not
    
    "services" that you use.  You're talking about what you *get* as a benefit from
    
    securing the data.  Your goal here, by securing the data, is to get
    
    authenticity an integrity, but not confidentiality.  Please re-word this
    
    accordingly.  You also say "privacy" right after this.  Do you really mean
    
    "privacy", or should it be "confidentiality"?
    
    
    
    -- Section 2.3 --
    
    OLD
    
       3.  Ensure that the improved security solutions on currently running
    
           routing infrastructure equipment are deployable.  This begs the
    
           consideration of the current state of processing power available
    
           on routers in the network today.
    
    
    
    This is a bit awkward in phrasing.  I suggest this:
    
    NEW
    
       3.  Ensure that the improved security solutions are deployable on
    
           currently running routing infrastructure equipment.  This requires
    
           consideration of the current state of processing power available
    
           on routers in the network today.
    
    
    
    But anyway, isn't this part of item 4, "Operational deployability"?
    
    
    
    In item 4:
    
    OLD
    
          F. There are three use cases for operational peering at play
    
              here: peers and interconnection with other operators, iBGP,
    
              and other routing sessions within a single operator, and
    
              operator-to-customer devices.
    
    
    
    I'm not sure I see the three cases.  I think the problem is that one of the
    
    cases is itself a list with commas.  You should use semicolons in the outer
    
    list when that happens, but in this case maybe you just need to remove the
    
    comma after "iBGP"?
    
    
    
    -- Section 2.4 --
    
    Privacy and confidentiality are not the same thing; please don't use them
    
    interchangeably.  You mean confidentiality, and you should probably scrub the
    
    document of all instances of "privacy", because this happened in Section 2.1 as
    
    well.
    
    
    
    -- Section 3.1.2.1 --
    
    The second paragraph is long, rambling, confused, and confusing.  Please
    
    tighten it, trim it, and take out the unnecessary stuff about "well, he could
    
    be an INSIDER, and he could be BYZANTINE, but he's unauthorized, and then he's
    
    *really* unauthorized, so then he's an OUTSIDER and......"  May I suggest this
    
    for the whole paragraph?: NEW
    
       A terminated employee, once an INSIDER, becomes unauthorized
    
       and an OUTSIDER at the point of termination -- no longer a legitimate
    
       participant in the routing system.  It behooves the operator to change
    
       the keys, to enforce the revocation of authorization of the old keys, in
    
       order to minimize the threat source's window of opportunity.
    
    
    
    The last two paragraphs also repeat themselves, and should probably be merged. 
    
    For instance, the penultimate one says that key changes need to happen "very
    
    quickly, with zero impact to the routing system, and with little operational
    
    expense," and the last paragraph says, "quickly with minimal impact to the
    
    routing system, at low operational cost."  Whether zero or minimal, you
    
    shouldn't say the same thing twice in two paragraphs.  Do a merger here.
    
    
    
    -- Section 3.2 --
    
          attacker sends
    
          spoofed packets aimed at halting or preventing the underlying
    
          protocol over which the routing protocol runs.
    
    
    
    I can't parse "preventing the protocol".  "Halting the protocol" is OK, but
    
    "preventing" doesn't work the same way (you have to prevent it *from doing
    
    something*).  Re-word.
    
    
    
    More general: are all DoS attacks on the routing system really spoofing
    
    attacks?  In general, some DoS attacks are done by spoofing and some aren't. 
    
    Is that not the case with routing attacks?  (I don't know; I'm asking.)
    
    
    
    -- Section 4 --
    
    Requirement 2:
    
            Strong cryptographic algorithms, as defined and accepted by the
    
            IETF security community, MUST be specified.  The use of non-
    
            standard or unpublished algorithms SHOULD BE avoided.
    
    
    
    These are contradictory: non-standard and unpublished algorithms won't be
    
    accepted by the IETF security community, and so are already declared MUST NOT
    
    by the first sentence.  Make it "MUST be avoided," or "MUST NOT be used."
    
    
    
    Requirement 3:
    
            Algorithm agility for the cryptographic algorithms used in the
    
            authentication MUST be specified, i.e. more than one algorithm
    
            MUST be specified and it MUST be clear how new algorithms MAY be
    
            specified and used within the protocol.
    
    
    
    Hm.  You don't really need to have more than one algorithm specified; you just
    
    have to *be able* to specify more than one, and have a way to add new ones. 
    
    This requirement isn't meant to say that if only one suitable algorithm exists
    
    at the time the protocol is written, that's a problem.  The "MAY" is also an
    
    improper use of 2119 language.  How about this?:
    
    
    
    NEW
    
            Algorithm agility for the cryptographic algorithms used in the
    
            authentication MUST be specified.  That is, it MUST be possible to
    
            choose which algorithm is being used, and  it MUST be clear how
    
            new algorithms are specified and used within the protocol.
    
    
    
    You may also need to make changes later in the paragraph, where you say
    
    "Mandating two algorithms".
    
    
    
    Requirement 5:
    
    Item "A" seems out of place here.  It's not a requirement nor an explanation of
    
    one.  It's a specific threat that you've stuck in the middle of the
    
    requirements section.  (I also don't see how it directly relates to requirement
    
    5.)  It should be moved elsewhere (maybe a new Section 3.1.3?).
    
    
    
    Requirement 6:
    
            A change of security parameters REQUIRES, and even forces, a
    
            change of session traffic keys.
    
    
    
    "REQUIRES" is not a 2119 word.  If you want to keep 2119 language here, maybe
    
    this: NEW
    
            A change of security parameters MUST force a
    
            change of session traffic keys.
    
    
    
    Otherwise, just make "requires" lower case.
    
    
    
    Requirement 7:
    
            Intra-session re-keying which occurs without a break or
    
            interruption to the current routing session, and, if possible,
    
            without data loss, MUST be specified.
    
    
    
    There's a little too much in there, and "if possible" seems not to go so well
    
    in the same sentence as MUST.  How about this?: NEW
    
            Intra-session re-keying that occurs without a break or
    
            interruption to the current routing session MUST be
    
            specified.  If possible, this ought to happen without
    
            data loss.
    
    
    
    Requirement 22:
    
    The second paragraph looks like it should be a separate requirement, number 23.
    
    
    
    -- Section 5 --
    
    The second Security Considerations paragraph doesn't seem to belong here. As
    
    with paragraph "A" in requirement 5, above, it really looks like it should be
    
    moved to the threats discussion, and, in fact, seems like a variation of that
    
    attack (a variation that's performed by a Byzantine insider).  I suggest
    
    putting both attacks into a new Section 3.1.3, because they're so closely
    
    related.
    
    
    
    The first paragraph of the Security Considerations seems to stand alone as
    
    sufficient for this document.
  4. Sean Turner: Discuss [2012-07-19]:
    Thanks to the authors for getting the draft this far.  First off a big mea
    
    cupla for following KARP and not getting to this earlier.
    
    
    
    Steve Kent's secdir review pointed out many issues with this draft.  Many of
    
    those are in the comments section and some are here.  I guess I'm willing to be
    
    shouted down that the following things turned up during the secdir aren't
    
    blocking, but I think we might be doing a disservice to others if we don't fix
    
    these because I find the draft hard to follow and some of the requirements are
    
    vague.
    
    
    
    1) s1.1: The KDF definition lists four sources from which to generate keys. 
    
    Two seem to be the same, (i) a random or pseudorandom seed value and (iii) a
    
    non-uniform random source, I'd like to understand how they differ.
    
    
    
    2) s1.1: The KMP definition indicates that the KMP determines how secret keys
    
    are generated - this isn't always true.  Are you presupposing a solution? 
    
    Here's some suggested text:
    
    
    
    OLD:
    
    
    
     It determines how secret keys are generated and made
    
      available to both the parties.
    
    
    
    NEW:
    
    
    
     It determines how secret keys are made available to both
    
     parties and in some cases also determines how the secret
    
     keys are generated.
    
    
    
    3) s1.1: PRF vs KDF: The definitions look to be pretty similar.  It'd be worth
    
    saying how they're different or whether they're the same.  Often times PRFs are
    
    used in KDFs.  Maybe Brian can help with this based on
    
    (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kdf-uses/).
    
    
    
    4) s2.3 Step 4: Is there an agreement about the common operator teams and
    
    common deployment process?  How will this help evaluations?  Who will conduct
    
    the survey?  Who's going to perform the interviews?  Is there a citation for
    
    the interviews?
    
    
    
    5) s2.3: Step 4: Having some trouble parsing the following:
    
    
    
     Measurably, we
    
     would like to see an increase in the number of surveyed
    
     respondents who report deploying the updated authentication and
    
     integrity mechanisms in their networks, as well as a sharp rise
    
     in usage for the total percentage of their network's routers.
    
    
    
    Are you asking for more people to deploy and to fill out the surveys?
    
    
    
    6) s3.1.2: Stolen Keys (s3.1.2) aren't a threat source but Terminated Employees
    
    are (s3.1.2.1).
    
    
    
    6a) How about re-titling s3.1.2.1 to INSIDERS and moving it to s3.1.2 and
    
    moving s3.1.2 to somewhere else (not sure where yet).
    
    
    
    6b) RFC 4593 says there's two sources: outsiders (addressed) and byzantine
    
    (addressed). Are we updating RFC 4593 by adding a new type of adversary?
    
    
    
    7) s3.2: I thought a non-goal was "Message content validity (routing database
    
    validity)" so it's unclear why FALSIFICATION is in scope?
    
    
    
    8) s3.2: I know 4593 uses INTERFERENCE, but how are the things that are listed
    
    under that any different than the DoS attacks (or integrity violations that an
    
    attacker would try to us in a DoS attacks) introduced here?  In s3.3 you list
    
    DoS under INTERFERENCE so maybe we should try to make the two sections be more
    
    alike and group them together somehow.
    
    
    
    9) I know 4593 uses "noise" but how's that any different than inserting
    
    messages, replying out-dated messages, corrupting messages, changing message
    
    contents?  I can hear everybody saying it's in 4593 go away, but we don't have
    
    to continue to repeat the sins of our fathers/mothers.
    
    
    
    10) s3.2: The brute force paragraph indicates that the key should be long
    
    enough to thwart attacks 10 or more years out.  That's a big range - is it 11
    
    or 100 years?  The answer is going to drive the solution.
    
    
    
    11) s3.2/3.3: FALSIFICATION is listed as in scope in 3.2 and out of scope in
    
    3.3.  Very confusing.
    
    
    
    12) s4 #3: Algorithm agility is about being able to transition from one alg to
    
    another not supporting two MTI algs at the same time. I think #3 needs to be
    
    reworded.
    
    
    
    13) s4 #5: Needs more detail about inter- and intra-session replay protection.
    
    
    
    14) s4 #7: If keys are only changed when somebody leaves it is not very
    
    periodic, confidentiality is out-of-scope, and I'm not sure what you mean by
    
    entropy (are you saying to add more entropy - i.e., bigger key). How about:
    
    
    
     Intra-session re-keying which occurs without a break or
    
     interruption to the current routing session, and, if possible,
    
     without data loss, MUST be specified.  Keys need to be changed
    
     periodically, for operational confidentiality (e.g. when an
    
     administrator who had access to the keys leaves an organization)
    
     and for entropy purposes, and a re-keying mechanism enables the
    
     operators to execute the change without productivity loss.
    
    
    
    To:
    
    
    
      Security mechanisms MUST specify a means to effect
    
      intra-session re-keying without disrupting a routing
    
      session.  Keys need to be changed periodically, for
    
      authentication and integrity (e.g., when an administrator
    
      who had access to the keys leaves an organization).
    
    
    
    15) s4 #7 & #8: Are #7 and #8 at odds?  Is there any other way to rekey an
    
    intra-session without sending the thing twice under two different keys?  Maybe
    
    "intra-" should be dropped?
    
    
    
    16) s4 #8: "Efficient" rekeying - how do we measure this?  One person's
    
    efficiency is another person's IPR ;)  Maybe this just needs to be reworded:
    
    
    
      Re-keying SHOULD be supported in such a way that it can occur
    
      during a session without the peer needing to use multiple
    
      keys to validate a given packet.
    
    
    
    17) s4 #12: Why not MUST consider and allow for future use of KMP?  I guess we
    
    could define one and then chuck it away but would we really do that?
    
    
    
    18) s4 #13: Levies the following requirement:
    
    
    
     It MUST be
    
     obvious how the keying material was obtained, and the process
    
     for obtaining the keying material MUST exist outside of the
    
     Routing Protocol.
    
    
    
    Obvious to some is not obvious to others.  I think this needs to be restated. 
    
    Is this just about a key identifier so you can locate it in the table?
    
    
    
    19) s4 #14: Levies a requirement of no more than 5% increase in convergence
    
    time.  It then goes on to say this time will be measured by router vendors and
    
    ISPs. Are folks not in that group going to be able to verify the data too?
    
    
    
    20) s4 #19: In the following:
    
    
    
     Proposed solutions MUST support an incremental
    
     deployment method that provides some benefit for those who
    
     participate.
    
    
    
    Who are those?  Is that inter- or intra-AS deployments?
    
    
    
    21) s5: Isn't the last paragraph in the security misplaced?  Ought it be in the
    
    mainbody describing what's in and what's out?
  5. Sean Turner: Comment [2012-07-19]:
    There's a whole lotto these and I'm willing to provide the authors with an
    
    update .nroff or .txt file.
    
    
    
    1) abstract:
    
    
    
    OLD:
    
    
    
     Different routing protocols exist and each employs its own mechanism
    
     for securing the protocol packets on the wire.
    
    
    
    NEW:
    
    
    
      Different routing protocols employ different mechanisms
    
      for securing protocol packets on the wire.
    
    
    
    OLD:
    
    
    
     ... routing protocols' transport systems, including any
    
     mechanisms built into the routing protocols themselves, which
    
     accomplish packet authentication.
    
    
    
    NEW:
    
    
    
     ... routing protocol transport systems. This includes any
    
     mechanisms built into the routing protocols themselves, to authenticate
    
     packets.
    
    
    
    2) s1:
    
    
    
    OLD:
    
    
    
     This document addresses the last item in the list above, securing the
    
     transmission of routing protocol packets on the wire, or rather
    
     securing the routing protocols' transport systems, including any
    
     mechanisms built into the routing protocols themselves which
    
     accomplish packet authentication.  This effort is referred to as
    
     Keying and Authentication for Routing Protocols, or "KARP".  KARP is
    
     concerned with issues and techniques for protecting the messages and
    
     their contents between directly communicating peers.  This may
    
     overlap with, but is strongly distinct from, protection designed to
    
     ensure that routing information is properly authorized relative to
    
     sources of information.  Such assurances are provided by other
    
     mechanisms and are outside the scope of this document and work that
    
     relies on it.
    
    
    
    NEW:
    
    
    
     This document addresses the last item in the list above, securing
    
     the transmission of routing protocol packets on the wire. More
    
     precisely, it focuses on securing the transport systems employed by
    
     routing protocols, including any mechanisms built into the protocols
    
     themselves to authenticate packets.  This effort is referred to as
    
     Keying and Authentication for Routing Protocols, or "KARP".  KARP is
    
     concerned with issues and techniques for protecting the messages and
    
     their contents between directly communicating peers.  This may
    
     overlap with, but is strongly distinct from, protection designed to
    
     ensure that routing information is properly authorized relative to
    
     the source of the information.  Such assurances are provided by other
    
     mechanisms and are outside the scope of this document.
    
    
    
    In this text is the "their content" trying to distinguish between contents and
    
    headers but it's ambiguous.
    
    
    
    OLD:
    
    
    
     and to provide a set of requirements for KARP design teams to
    
     follow as they tackle [RFC6518], Section 4.1's "Work Phase 1", the
    
     update to a routing protocol's existing transport security.
    
    
    
    NEW:
    
    
    
     and to provide a set of requirements for KARP design teams to
    
     follow as they update a routing protocol's existing transport
    
     security (see [RFC6518], Section 4.1's "Work Phase 1’).
    
    
    
    OLD:
    
    
    
     Section 3 lists the
    
     threats from [RFC4593], Generic Threats To Routing Protocols, that
    
     are in scope for routing protocols' transport systems' per packet
    
     authentication.
    
    
    
    NEW:
    
    
    
     Section 3 lists the
    
     threats from [RFC4593] (Generic Threats To Routing Protocols) that
    
     are in scope for per-packet authentication for routing protocol
    
     transport systems.
    
    
    
    OLD:
    
    
    
     Individual
    
     protocol analysis documents will need to be more specific in their
    
     usage.
    
    
    
    NEW:
    
    
    
     Individual
    
     protocol analysis documents will need to be more specific in their
    
     use of this phrase.
    
    
    
    3) s1.1:
    
    
    
    Probably worth adding some text about the terms later defined in s3.1.
    
    
    
    Identity Authentication: The point here is that you get an authenticated
    
    identity after it's been verified.
    
    
    
    OLD:
    
    
    
     Once the identity is determined
    
    
    
    NEW:
    
    
    
     Once the identity is verified
    
    
    
    OLD:
    
    
    
     or an assymetric key containted in a certificate
    
    
    
    NEW:
    
    
    
     or an asymmetric key contained in a certificate.
    
    
    
    OLD:
    
    
    
     The use of these different identity authentication
    
    
    
    NEW:
    
    
    
     The use of these different identity verification
    
    
    
    For the next one it's not clear what's meant by "ongoing effort".  I'd just
    
    delete it because I think that supposed to be management.
    
    
    
    OLD:
    
    
    
      ongoing effort and management
    
    
    
    NEW:
    
    
    
      management
    
    
    
    OLD:
    
    
    
     For example, they differ in resistance
    
     to a security breach, and the effort required to remediate the
    
     whole system in the event of such a breach.
    
    
    
    NEW:
    
    
    
     For example, they differ in resistance
    
     to a security breach, and the effort required to recover
    
     in the event of such a breach.
    
    
    
    KDF: The or derive part isn't really needed.
    
    
    
    OLD:
    
    
    
     A KDF is a function in which an input key and other input data is
    
     used to generate (or derive) keying material that can be employed
    
     by cryptographic algorithms.
    
    
    
    NEW:
    
    
    
     A KDF is a function in which an input key and other input data is
    
     used to generate keying material for use with
    
     cryptographic algorithms.
    
    
    
    NEW:
    
    
    
    and r/a truly random/a random
    
    
    
    KMP:
    
    
    
    r/(or a group)/(or among a group)
    
    
    
    The last paragraph isn't really need it's is copied from the RFC 6518.
    
    
    
    KMP Function:
    
    
    
    r/Any actual/Any
    
    
    
    Peer Key
    
    
    
     r/authentication mechanism used ina/uthentication mechanism are used in
    
     r/a KMP that would/a KMP and would
    
    
    
    PRF:
    
    
    
     r/PRF/Pseudorandom Function (PRF)
    
     r/efficiently-computable functions, which emulate
    
      /efficiently-computable functions that emulate
    
    
    
    Routing Protocol: Since this is about the last item in the intro we should
    
    stick with that terminology:
    
    
    
     r/to provide or enhance its peer authentication mechanisms
    
      /to its packets on the wire
    
    
    
    SA:
    
    
    
    OLD:
    
    
    
      Examples of items that may
    
      exist in an SA include: Identifier, PSK, Traffic Key,
    
      cryptographic algorithms, key lifetimes.
    
    
    
    NEW:
    
    
    
      Examples of attributes that may be associated with an SA include:
    
      Identifier, PSK, Traffic Key, cryptographic algorithms, key lifetimes.
    
    
    
    Traffic Key:
    
    
    
    OLD:
    
    
    
     protecting the routing protocol traffic.  Since the traffic keys
    
     used in a particular connection are not a fixed part of a device
    
     configuration no data exists anywhere else in the operator's
    
     systems which can be stolen, e.g. in the case of a terminated or
    
     turned employee.  If a server or other data store is stolen or
    
     compromised, the thieves gain no access to current traffic keys.
    
    
    
    NEW:
    
    
    
     protecting routing protocol traffic. A traffic key should not be
    
     a fixed value in a device configuration. A traffic key should be
    
     known only to the participants in a connection, so that a
    
     compromise of stored , e.g. in the case of a terminated or
    
     turned employee, does not result in disclosure of traffic keys.
    
     If a server or other data store is stolen or compromised,
    
     the attackers gain no access to current traffic keys.
    
    
    
    4) s2.1:
    
    
    
     Lines up with the three services listed earlier:
    
     r/privacy service/confidentiality
    
    
    
     r/have existing/incorporate
    
    
    
     r/and both have/and have (there's four protocols listed earlier assume you
    
     mean all four)
    
    
    
     r/use of existing/use of existing (exist is used later so remove this one or
    
     the later one)
    
    
    
     (I think you're trying to say with the Routing Protocol)
    
     r/with the bits-on-the-wire mechanisms
    
      /Routing Protocol
    
    
    
    5) s2.2:
    
    
    
     r/The work/This document
    
     r/The roadmap for any one routing protocol/The roadmap for any routing protocol
    
     r/The performance impact of any incremental step of security improvement
    
      /The performance impact of any incremental security improvement
    
     r/However,in the spirit of incremental deployment, we first
    
      /However, in the spirit of incremental deployment, the IETF first
    
    
    
    6) s2.3:
    
     r/the wire of existing/the wire for existing
    
     r/in the earlier sections/in Section 2.2.
    
    
    
    OLD:
    
    
    
     Ensure that the improved security solutions on currently running
    
     routing infrastructure equipment are deployable.  This begs the
    
     consideration of the current state of processing power available
    
     on routers in the network today.
    
    
    
    NEW:
    
    
    
     Ensure that the improved security solutions is deployable on the
    
     current routing infrastructure.  The current state of processing
    
     power available on routers will need to be investigated.
    
    
    
     Get rid of "we"
    
     r/to ensure that what we specify can
    
      /to ensure that what solutions can be specified
    
    
    
     r/Protoco/Protocol
    
     r/The survey/The survey [ISR2008]
    
    
    
     Get rid of our - I've heard this too :)
    
     r/From our personal conversations with operators, of those using MD5,
    
      /Anecdotal evidence from operators using MD% shows
    
    
    
     r/as cumbersome/as cumbersome to manage securely
    
     r/threat at play here/threat here
    
    
    
     r/security and threat protection/security
    
    
    
    6) s2.4:
    
    
    
     r/privacy/confidentiality
    
     r/efforts, like SIDE/working groups (e.g., SIDR).
    
    
    
    7) s2.5:
    
    
    
     r/with updates to the Routing/with updating Routing
    
     r/with close/in close
    
     r/are delegated/are tasked
    
    
    
    OLD:
    
    
    
     ... , presumably due to a perception of significantly
    
     improved security value coupled with relative similarity to
    
     deployment complexity and cost.  Conversely, the work will be
    
     considered a failure if the operators do not care to deploy it,
    
     either due to lack of value or perceived (or real) over-
    
     complexity of operations.
    
    
    
    NEW:
    
    
    
     ... . It is anticipated that deployment will take place
    
     only if operators perceive that the improved security offered
    
     by the Routing Protocol updates warrant the complexity and cost
    
     of deployment and opertation.  Conversely, the work will be
    
     considered a failure if operators do not deploy it,
    
     either due to lack of perceived value or due to perceived
    
     operational complexity.
    
    
    
    8) s3:
    
    
    
     r/"threat" defined in/"threat" from
    
     r/and simply listing/and listing
    
    
    
    OLD:
    
    
    
     As such, the below text intentionally does not constitute
    
     a self-standing, complete threat analysis, but rather describes the
    
     applicability of the existing threat analysis [RFC4593]relevant to
    
     KARP.
    
    
    
    NEW:
    
    
    
     As such, the following text intentionally is not a comprehensive
    
     threat analysis. Rather it describes the
    
     applicability of the existing threat analysis [RFC4593] to
    
     KARP.
    
    
    
    9) s3.1.
    
    
    
    The BYZANTINE sources should be listed here to align with [RFC4593].  Then you
    
    can say they're out of scope in s3.3.
    
    
    
    10) s3.1.1:
    
    
    
     r/sources/attackers
    
     r/path of packets between the two routing/path between two routing
    
     r/attacker actually/attacker
    
     r/attacker only/attacker
    
     r/treat/reject
    
     r/may often eventually/may
    
    
    
    An MitM can also spoof packets.  So maybe:
    
    
    
    11) s3.1.2 (assuming it'll get moved someplace):
    
    
    
     r/router A to router B/router A, destined for router B
    
     r/having/one has
    
     r/The stolen keys,/The stolen keys
    
     r/keying material will become necessary with little or
    
       no advanced warning
    
      /keying material will need to be put in place with little
    
       or no advanced warning
    
     r/short, or make nonexistent,/short
    
     r/the source with stoke keys attack by creating
    
      /this type of attack by
    
     r/habitually/regularly (frequently)
    
    
    
    12) s3.1.2.1:
    
    
    
     To avoid any confusion just use the definition from 4593
    
     r/On the other hand, they aren't really a BYZANTINE
    
       attacker, which is defined to be an attack from an INSIDER, a
    
       legitimate router
    
      /One the other hand, they aren't really a BYZANTINE attacker which
    
       is defined in [RFC4593] as: faulty, misconfigured, or subverted
    
       routers; i.e., legitimate participants in the routing protocol.
    
     r/to be legitimate participants/to be a legitimate participant
    
     r/"insider"/INSIDER
    
    
    
    13) s3.2:
    
    
    
    Title and first sentence don't match.  assume r/ATTACK/THREAT.  Lines up nicely
    
    with 4593.
    
    
    
    SPOOFING: I hate to copy text, but it might really help to copy this bit from
    
    4593 about spoofing as a  second sentence:
    
    
    
     Spoofing is special in that it can be used to carry out
    
     other threat actions causing other threat consequences.
    
    
    
    I tend to agree with Steve, if this is an example of Spoofing then I'm not sure
    
    why it's not indented below SPOOFING.
    
    
    
    It would make more sense to have one DoS bullet and say that DoS involving the
    
    routing protocol is in scope (opposite of what's in the out-of-scope section),
    
    generally describe DoS, and then give two examples.  There might be a bunch of
    
    others that we think of later.
    
    
    
    14) s3.3:
    
     r/(Section 2.1)/(Section 3.2)
    
     r/SNIFFING/SNIFFING (passive wiretapping) - you mentioned active wiretapping
    
     earlier so it only makes sense to add it here. r/privacy/confidentiality
    
    
    
    15) s4:
    
    
    
     r/how each of the below requirements are met
    
      /how each of the following requirements are met
    
    
    
    Please do a review of the 2119-language to make sure that all the MUSTs/SHOULDs
    
    are capitalized.  Also sometimes the "p" isn't capitalized in Router protocols
    
    when maybe it should.
    
    
    
    #1: r/by the authentication mechanism/by an authentication/integrity mechanism
    
    
    
    #5: r/The ability … IP address.
    
         /The ability to run a MAC operation with K is used
    
          for (group-level) authentication  and message integrity, and
    
          (currently) no other authentication check is performed.
    
    
    
    #6: r/REQUIRES, and even forces,/MUST trigger
    
    
    
    #9: r/must/MUST
    
        r/filter/reject
    
    
    
    #10:
    
     r/for a routing protocol/for each routing protocol security mechanism
    
     r/at or below/at
    
     Not sure you need the explanation to understand the requirement - just delete
    
     that bit.
    
    
    
    #11: r/For backward compatibility reasons/For backward compatibility reasons,
    
    
    
    #12: r/Architecture of the/The
    
    
    
    #13: r/the Routing/a Routing
    
         r/This will allow for the various key
    
            generation methods, like manual keys and KMPs, to be used with
    
            the same Routing Protocol mechanism.
    
          /This will accommodate both manual keying and use of KMPs and use of
    
          KMPs./
    
    
    
    #14: I don't think the alternate way of stating the requirement adds anything -
    
    it's really squishy: minimal increase.  I'd drop it.
    
      Also, does this contradict the earlier measurement criteria, which WILL be
    
      affected by specific implementations. Which criteria do you really want to
    
      employ?
    
    
    
    #15: r/advertisments/advertisements
    
    
    
    #17: r/Routing protocols MUST only send minimal information regarding
    
           the authentication mechanisms and the parameters in its protocol
    
           packets.  One reason for this is to keep the Routing Protocols
    
            as clean and focused as possible, and load security negotiations
    
            into the future KMP as much as possible.
    
          /The Routing Protocol MUST send minimal information regarding the
    
           the authentication mechanisms and associated parameters in its protocol
    
           packets.  This keeps the Routing Protocols
    
            as clean and focused as possible, and loads security negotiations
    
            into the KMP as much as possible.
    
    
    
    #18: r/seperate/separate
    
         r/that are based on this requirement/that motivate this requirement
    
    
    
    #19:  The 2nd and 3rd sentences are redundant.  Delete the 3rd.
    
    
    
    #19:
    
     B: r/compatibility in the message/compatibility with respect to message
    
     B: r/mixed security/secure and non-secure
    
     C: r/systems/routers
    
    
    
    #20: r/to destabilize routers/to degrade router perform
    
    
    
    #22:
    
     r/for the routing system to function/for the routing system to be secure
    
     r/information/security association?  (If by information you mean shared secret
    
     key)? r/okay/acceptable X2

draft-ietf-cdni-use-cases

  1. Benoit Claise: Discuss [2012-07-19]:
    I support this document, one easy-to-fix DISCUSS though
    
    Section 1.1 Terminology
    
       We adopt the terminology described in
    
       [I-D.ietf-cdni-problem-statement], and [I-D.ietf-cdni-framework].
    
    
    
    We need to read the terminology from [I-D.ietf-cdni-problem-statement] in order
    
    to understand this draft. So this should be a normative reference, right? Note:
    
    this is fine since the cdni-problem-statement is now in the RFC-editor queue.
    
    
    
    However, wrt [I-D.ietf-cdni-framework], I don't think it's fine to have an
    
    informative reference (regarding terminology) to a future document. What if the
    
    definitions change after this document publication, will this document still be
    
    readable? Maybe yes, maybe no. The good news is that the 7 terms defined in
    
    [I-D.ietf-cdni-framework] are not used in this document. So you should simply
    
    remove "and [I-D.ietf-cdni-framework]"
  2. Benoit Claise: Comment [2012-07-19]:
    - Title says "1.3.  Rationale for Multi-CDN Systems" but the content is about
    
    CDN Interconnection. Shouldn't the title be "Rationale for CDN
    
    Interconnection"? Or maybe I missed a subtle difference between the two terms?
    
    
    
    - I like the fact the terms defined in [I-D.ietf-cdni-problem-statement] are
    
    capitalized. It would be nice to clearly mention that in the terminology
    
    section. It helps a lot the reader as he doesn't know what he doesn't know
    
    (i.e. that a term is defined somewhere else.). Yes sure, you wrote "We adopt
    
    the terminology described in [I-D.ietf-cdni-problem-statement]" that would help
    
    the reader anyway.
    
    
    
    Example: rfc5982
    
       The IPFIX-specific and PSAMP-specific terminology used in this
    
       document is defined in [RFC5101] and [RFC5476], respectively.  In
    
       this document, as in [RFC5101] and [RFC5476], the first letter of
    
       each IPFIX-specific and PSAMP-specific term is capitalized along with
    
       the IPFIX Mediation-specific terms defined here.
    
    
    
    Note: I haven't checked the consistency of the capitalization
    
    
    
    - " The End User benefits from this arrangement through a better Quality
    
       of Experience (QoE), "
    
    
    
    QoE definition in RFC6390
  3. Adrian Farrel: Comment [2012-07-19]:
    Was nothing learnt from RFC 3570 and no mention or acknowledgement of
    
    the authors of that work due?
    
    
    
    ---
    
    
    
    Would it be possible to add a figure to Section 3? They are very helpful
    
    in 1.3 and 2.4.
    
    
    
    ---
    
    
    
    Section 8 could point to A.2
  4. Stephen Farrell: Discuss [2012-07-16]:
    
    I am concerned that this document is fairly full of DRM
    
    related use cases, when DRM mechanisms are explicitly ruled
    
    out of scope by the WG charter.
    
    
    
    - The "distribution rights" example in 1.3 is basically a
    
    DRM thing.
    
    
    
    - The last paragraph of 2.4 (referring to A.1) is also a DRM
    
    example.
    
    
    
    - The second paragraph of 3.1 talks about "exclusive
    
    distriubtion rights."
    
    
    
    - A.1 refers explicitly to "license violations."
    
    
    
    - A.2 refers to "content protection"
    
    
    
    - It seems therefore that section 5 is thus not justified
    
    with the current DRM-only examples.
    
    
    
    Are there no better (technical) reasons why policy needs to
    
    be applied that could be used as examples?  Note: I'm not
    
    saying these examples are "wrong" but rather that we need
    
    non-DRM use-cases to motivate things.
  5. Stephen Farrell: Comment [2012-07-16]:
    
    - I don't get how End-user B in 2.4, who's not allowed
    
    access stuff, is relevant for CDNI. Are you saying that CNDI
    
    protocols will carry authentication or authorization PDUs
    
    specific to end-users? I didn't think that was going to be
    
    the case.
    
    
    
    - Another patent declaration on a use-cases document. Sigh.
    
    (No action is required, I'm just lamenting;-)
  6. Russ Housley: Comment [2012-07-17]:
    
      Please consider the editorial comment from the Gen-ART Review by
    
      Suresh Krishnan on 16-July-2012.  The review can be found here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07608.html
  7. Barry Leiba: Comment [2012-07-10]:
    Totally trivial:
    
    
    
    -- Abbreviations --
    
    
    
       WiFi: Wireless Fidelity
    
    
    
    Really?  You made that up, right?  I suggest this:
    
    WiFi: Wireless local area network (WLAN) based on IEEE 802.11.
    
    (Or just the first part.)
  8. Sean Turner: Comment [2012-07-18]:
    0) Process Question: Do you want to also make RFC 3570 historic?
    
    
    
    1) Stephen beat me to the DRM issue - needless to say I agree with him.
    
    
    
    2) s1.2: DRM is listed but not used in the draft.  Use it or lose it :)
    
    
    
    3) a/s1/s1.3/s2.1: Anytime I see "cost" I think marketing.  Honestly think you
    
    could elide the cost discussion from the draft and it would be fine.  Besides
    
    cost savings are already called out in the problem statement.  (reminder this
    
    is a non-blocking comment).

draft-ietf-ippm-twamp-value-added-octets

  1. Stewart Bryant: Discuss [2012-07-16]:
    
    I am concerned that there is no provision in the protocol to identify the
    
    vendor who has defined the extension. Thus if one equipment is deploying this
    
    extension, and it's peer is from another vendor, there appears to be no way for
    
    the two equipments to resolve the semantics of the extension that each may be
    
    attempting to use.
    
    
    
    The best approach in these circumstances would seem to be to publish an update
    
    to RFC5357 providing a well defined vendor extension mechanism including a
    
    vendor identifier, and then to carry this added value information behind the
    
    vendor identifier.
  2. Benoit Claise: Discuss [2012-07-18]:
    
    - The last part of the paragraph concerns me:
    
    
    
       This memo contains the description of a working prototype. It does
    
       not represent a consensus of the IETF community. The IETF community
    
       is currently working on the problem statement and has not reached
    
       consensus on the preferred method for measuring capacity metrics.
    
    
    
    So basically, you want to document a prototype, for which the IETF community is
    
    currently working on problem statement? What do I miss?
    
    
    
    - The way I understand the two following paragraphs ...
    
    
    
       The definition of a structure for embedding a sequence of
    
       value-added fields at the beginning of the Packet Padding field
    
       [RFC5357] or Packet Padding (to be reflected) field [RFC6038]
    
       in the TWAMP test packets and, ...
    
    
    
       ...
    
    
    
       This memo assumes the TWAMP responder is configured through non-
    
       standard means to interpret the value-added padding octets embedded
    
       in each TWAMP test packet.
    
    
    
    ... is that you want to document a cover channel. I mean, the semantic of what
    
    you include is completely unknown as far as I can tell. Again, what do I miss?
    
    
    
    - I support Stewart's and Robert's DISCUSS
    
    
    
    - Regarding the following sentence ...
    
    
    
       Assignment of a proprietary TWAMP mode communicated during
    
       TWAMP control connection setup
    
    
    
    ... I don't see any reference to proprietary TWAMP mode in RFC5357.
    
    Practically, how is it done?
    
    
    
    I'm wondering if you should not specify an "experimental" mode, and specify
    
    this document as using this "experimental" mode, avoiding any potential clash.
    
    The following two sentences seem contradictory to me
    
    
    
       This memo does not extend the standard modes of operation through
    
       assignment of a new value in the Modes field (see Section 3.1 of
    
       [RFC4656] for the format of the Server Greeting message). A new mode
    
       is recommended to communicate feature capability during control
    
       connection setup.
  3. Adrian Farrel: Discuss [2012-07-19]:
    The "Document Quality" section of the ballot write-up seems to be
    
    missing (it just shows the questions).
    
    
    
    ---
    
    
    
    I would like to discuss this point with the rest of the IESG during the
    
    telechat before updating my ballot.
    
    
    
    Notwithstanding the working group's non-objection to the publication of
    
    this document, it seems like an end-run on the working group process. As
    
    I understanding it, the working group has agreed that there is a problem
    
    to be described and resolved inthis area, but has not agreed that this
    
    is the right problem or the right solution. Doesn't publication of this
    
    document encourage adoption of this specific solution without agreement
    
    from the WG?
    
    
    
    For example, the text says:
    
    
    
       The purpose of this memo is to describe the Ericsson TWAMP Valued-
    
       Added Octets feature (version 1) for TWAMP [RFC5357].
    
    
    
    But that hides the real puprpose. Why is there a need to describe the
    
    feature in an RFC?
    
    
    
    ---
    
    
    
    I would also like to understand better the way in which this document
    
    relates to existing and future standard implementations. The text
    
    states:
    
    
    
       This memo assumes the TWAMP responder is configured through non-
    
       standard means to interpret the value-added padding octets embedded
    
       in each TWAMP test packet.
    
    
    
    This assumption is fine as far as it goes, but you need to document
    
    what happens when there is a mismatch of configuration. How will a
    
    legacy node react if it receives this form of overloading? How will an
    
    Ericsson node react if it receives normal padding? What will happen if
    
    a future standards track document uses the padding in a different way?
    
    
    
    Furthermore, this document seems to specify a crass overloading of
    
    fields when it would be more appropriate to define a correct protocol
    
    extension. Such overloading often leads to interoperability issues
    
    with implementations that do strict checking or with future extensions
    
    that assign previously reserved bits for specific uses.
    
    
    
    As 5357 states...
    
    
    
       Packet Padding in TWAMP-Test SHOULD be pseudo-random (it MUST be
    
       generated independently of any other pseudo-random numbers mentioned
    
       in this document).  However, implementations MUST provide a
    
       configuration parameter, an option, or a different means of making
    
       Packet Padding consist of all zeros.  Packet Padding MUST NOT be
    
       covered by the HMAC and MUST NOT be encrypted.
    
    
    
    Given this, I don't see how backward compatiblity can be achieved or how
    
    the Ericsson extensions can be secured.
  4. Russ Housley: Comment [2012-07-15]:
    
      Please consider the editorial comment from the Gen-ART Review by
    
      Peter Yee on 28-June-2012.  The review can be found here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07564.html
  5. Robert Sparks: Discuss [2012-07-18]:
    The document encourages proprietary use (essentially, squatting) in a space
    
    reserved for expanding the protocol. In general that's proven to be a problem
    
    for other protocols. Can the document say why this one is different? Since an
    
    out of band agreement would need to be made before using a proprietary mode
    
    value, why use it at all instead of just relying on configuration of each end?

draft-ietf-oauth-urn-sub-ns

  1. Russ Housley: Comment [2012-07-15]:
    
      Please consider the editorial comment from the Gen-ART Review by
    
      Ben Campbell on 3-July-2012.  The review can be found here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07576.html
  2. Sean Turner: Comment [2012-07-16]:
    Consider Tero Kivinen's suggestion to add a similar note than what is in
    
    RFC2141 because adding pointer to another document which says "there is
    
    nothing here", isn't that helpful.

draft-ietf-dnsop-dnssec-dps-framework

  1. Stephen Farrell: Comment [2012-07-17]:
    
    - 1.1: Is this really for "users" to evaluate the strength of
    
    DNSSEC? I don't know any users who'd do that.  Maybe admins
    
    of some sort.
    
    
    
    - PKI definition: I'd love if you deleted non-repudiation
    
    since a PKI, and DNSSEC in particular, doesn't get you that.
    
    (By itself.)
  2. Russ Housley: Discuss [2012-07-18]:
    
      It seems that a DNSSEC signer can start out under one set of policy
    
      documents, and then for whatever reason the policy changes and the
    
      DNSSEC signer starts using a revised policy.  In this situation, the
    
      parties validating the signature have no means to determine that the
    
      signer is following a different policy.  Please explain the value of
    
      the policy to the parties that rely on these signatures.  At a minimum
    
      this possibility needs to be explained in the Security Considerations.
  3. Russ Housley: Comment [2012-07-18]:
    
      These comments come from a discussion with one of the authors of
    
      RFC 3647:
    
    
    
      DNSSEC Policy definition seems off target to me.  Are these all of the
    
      requirements or just the security requirements?
    
    
    
      The definition of PKI is not wrong, but it misses an important element
    
      that is important in the DNSSEC context too.  That is, the system
    
      depends on trusted distribution of public keys.
    
    
    
      The definition of Signing Key is incomplete.  The private key is used
    
      to sign.  The corresponding public key is used to validate the
    
      signature.  This is especially important when this definition is
    
      used in conjunction with the definition of Trust Anchor.  A Trust
    
      Anchor only includes the public key.  One way to resolve this is
    
      to define Key Pair or Asymmetric Key Pair.
    
    
    
      I think that Page 7 and 8 could be more clear.  A DP is a statement of
    
      security requirements (not principles).  The DP is best used to
    
      communicate requirements that must be met by complying parties; as
    
      such it may also be used to determine or establish equivalency between
    
      policies associated with different DNS zones.  A DPS describes the
    
      actual controls employed to meet the requirements of applicable DP.
    
    
    
      In Section 4.4.2, please consider the addition of a crypto officer
    
      that controls the private keys.  Also, which of the listed admin
    
      roles is responsible for the DNS and the network?
    
    
    
      In Section 4.4.4, please consider other records that may need to be
    
      kept for a period of time, such as records of key roll over, the
    
      personnel assigned to various roles, child zone manager verification,
    
      and so on.
    
    
    
      On Page 18, two person control is a special case of n out of m, where
    
      n = 2 and m is >= 2.
    
    
    
      In Section 4.5.2, please consider moving items 3 and 5 to another
    
      section.  The points are not about the signing environment; they are
    
      about the recovery of the signing private key after a failure of some
    
      sort.
    
    
    
      *****
    
    
    
      These comments are a portion of the Gen-ART Review by Peter Yee:
    
    
    
      Section 4.4.5 discusses how to handle key compromise.  It might be
    
      useful to discuss here or somewhere else in the document how the
    
      compromise is prevented from recurring if there were no attenuating
    
      measures in place beforehand.  That might well lead to a revision of
    
      the DP or DPS.  The draft doesn't really discuss under what
    
      circumstances a document should be iterated or amended.
  4. Barry Leiba: Discuss [2012-07-19]:
    From the shepherd writeup:
    
    > There was a concern about a possible copyright issue, but only in
    
    > respect to a pre-RFC5378 RFC.  Parts of RFC 3647 have been used in the
    
    > draft, so the authors have contacted the authors of RFC 3647 requesting
    
    > permission to use text from it.  All who have replied (four out of five)
    
    > have given that permission.
    
    
    
    The document doesn't have the pre-5378 boilerplate and, unless the fifth 3647
    
    author replies, it needs it.  This DISCUSS is a reminder to make that change.
  5. Sean Turner: Discuss [2012-07-19]:
    Having written a couple of CPs and CPSs (and depending on how you look at it
    
    that's either ;) or :( )
    
    
    
    1) Is it purely political that you're including the following "There are no
    
    agreements with the relying parties."
    
    
    
    Is the "yet" coming once a DPS is written?  It can be pretty easily argued that
    
    publishing a DPS is a form of agreement.  Those that use the signatures are
    
    relying on them to do x and y but not z.  Or are you simply trying to telling
    
    people to not write RP agreements?
    
    
    
    2) So I hope I'm not stepping in it here, but there's a couple of places where
    
    the draft discusses TA distribution. Isn't that already addressed with adequate
    
    documentation - and can't you just point to that?  I.e.:
    
    https://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt.
    
    
    
    Further, I thought the goal of DNSSEC was to encourage IANA as *the* TA.  Some
    
    of the wording seems to not entirely support that.  Was this done purposely?
    
    
    
    3) This ought to be easy to clear up but I wanted to check on this:
    
    
    
    s4.6.1: Are the changes to the algorithms performed according to IETF process? 
    
    Should this section explicitly call that out?
  6. Sean Turner: Comment [2012-07-19]:
    This so short for a policy document! :)  I also saw that Russ had a lengthy set
    
    of comments, and I apologize for not having time to skim through them and look
    
    for duplicates.  These are primarily based on a review by Steve Kent.
    
    
    
    1) s1: Do you want to also be able to check that the data hasn't been verified
    
    while in the cache:
    
           r/that it has not been modified in transit/
    
            /that it has not been modified in transit or in storage (e.g., caching).
    
    
    
           r/comprising statements of critical
    
            /comprising statements describing critical
    
    
    
    2) About the differences between a PKI and DNSSEC:
    
    
    
    2a) There is also no central control of assurance or trust levels in a PKI
    
    either ;)
    
    
    
    2b) You could argue that in PKIX each CPS defines their own way of managing
    
    keys - i.e., the same PKIs.
    
    
    
    2c) Weakest link the certification path is akin to the weakest link in the DNS
    
    link.
    
    
    
    I'm not sure you need the whole justification for why we're different bit. 
    
    Just say you borrowed from it and move on -that way you'll avoid all the but
    
    this is the same arguments/confusion.  How about:
    
    
    
     This document is heavily inspired by the Internet X.509
    
     Public Key Infrastructure Certificate Policy and Certification
    
     Practices Framework [RFC3647].
    
    
    
    and r/Consequently, a/A
    
    
    
    3) s1.2: You will do it ;)
    
          r/aims to explain/explains
    
          r/aims to present/presents
    
    
    
    4) s2, Compromise: I guess you can define this however you want, but normally
    
    wouldn't include loss, modification, or unauthorized use in key compromise.  I
    
    mean the result revocation is the same as key compromise.
    
    
    
    5) s2, DNSSEC: I guess it could hurt to repeat the suite of RFCs here:
    
         r/IETF specifications that
    
          /IETF specifications [RFC4033][RFC4034][RFC4035] that
    
    
    
    6) s2, key rollover: Need to be more precise about which keys you're rolling
    
    over (both KSKs (which sign keys, not zones) and ZSKs?).
    
    
    
    7) s2, PKI: I'd just copy the definition from RFC 5280 to avoid comments :)
    
    
    
        the hardware, software, people, policies, and procedures needed to
    
        create, manage, distribute, use, store, and revoke public key
    
        certificates [RFC5280].
    
    
    
    8) s2, PA:
    
    
    
    8a) Is there a PA for every DP or is this an optional element of this
    
    architecture?
    
    
    
    8b) Later you use the term formal and informal PA.  These should be explained
    
    here.
    
    
    
    9) s2, repository (boarding on discuss) if you don't keep the TA public how is
    
    this supposed to work?
    
        r/should be kept public/must be made publicly available
    
    
    
    10) s2: I think you're also missing a definition for multi-party.  It's one
    
    step farther than separation of duties - and you do use the term later ;)
    
    
    
    11) s2: Now that I'm thinking about it should you also have a definition for
    
    assurance, DNSSEC participants (does this include both RPs and signers?),
    
    DNSSEC stateholders?
    
    
    
    12) s3.1: r/The DNSSEC/A DNSSEC - there will be more than one right
    
              r/determined/specified
    
              r/levels/levels of assurance
    
              r/The DPs constitue/A DP also constitues
    
              r/it is recognized as implementing/it claims to implement
    
    
    
    13) s3.2: Assume participant is signer?
    
              r/participant/signer
    
    
    
    14) s3.3: Unclear what "interoperation of a level of trust between zones"
    
    means.  Does it mean a DP may serve as a basis for establishing a common basis
    
    of trusted operation throughout a set of zones, or something like that?
    
    
    
    15) s3.3: r/one or more zones/one or more zones subordinate to that TLD
    
    
    
              r/ A zone operator may be required to write its own
    
       Practice Statement to support the Policy by explaining how it meets
    
       the requirements of the Policy.
    
               / A zone operator may be required to write its own
    
       Practice Statement to support the Policy, explaining how the operator meets
    
       the requirements of the Policy.
    
    
    
              r/Alternatively, a zone operator that
    
       is also the manager of that zone and not governed by any external
    
       Policy may still choose to disclose operational practices by
    
       publishing a DPS for the purpose of providing transparency and to
    
       gain community trust in the operations.
    
                /Alternatively, a zone operator that
    
       is also the manager of that zone, and not governed by any external
    
       DP, may choose to disclose operational practices by
    
       publishing a DPS. The zone operator might do so to provide transparency
    
       and to gain community trust in its operations.
    
    
    
               r/level of detail in their provisions
    
                /level of detail each expresses
    
    
    
             r/processes and controls
    
              /processes and controls, absent a controlling Policy.
    
    
    
    16) s3.4: In b and c, when you say contains do you mean the
    
    
    
             r/implemetor/implementer
    
             r/regardless/independent
    
             r/generally must not conflict with the
    
              /generally they must not conflict with the stipulations
    
    
    
    17) s3.4/4: So many people got confused by whether they had to include the
    
    sections in the CPS (and presumably in the DPS) that it is a really good idea
    
    to specify whether "no stipulation" and clause title should be included instead
    
    of omitting the clause.  It stops people from asking: did you mean to say
    
    something about X.
    
    
    
    18) s4.1.4: /administration Specification/Administration Specification
    
    
    
    19) s4.4:
    
    
    
       r/the DNSSEC related functions such as physical access, key
    
       management, disaster recovery, auditing, and archiving.
    
        /DNSSEC related functions. Such controls include physical access, key
    
       management, disaster recovery, auditing, and archiving.
    
    
    
       r/These non-technical security controls are critical for trusting
    
       DNSSEC signatures, since lack of security may compromise DNSSEC operations.
    
       For example, it could result in the creation of signatures with
    
       erroneous information or in the compromise of a Signing Key.
    
       Within each subcomponent, each type of control will usually need to
    
       be described separately.
    
        /These non-technical security controls are critical for trusting the
    
       signatures since lack of security may compromise DNSSEC operations.
    
       For example, it could result in the creation of signatures with
    
       erroneous information or in the compromise of the Signing Key.
    
       Within each subcomponent, separate consideration will usually need to
    
       be given to each entity type.
    
    
    
    20) s4.4.1: Includes the term "entity system".  I understand that it's from
    
    3647 and that might refer to the RA or CA or whatever, but what's it refer to
    
    here?
    
    
    
    21) s4.4.4: r/and provide/and to provide
    
    
    
    22) s4.4.4: The phrase "access the systems" is from 3647 and it refers to a
    
    CA/RA, what's it refer to here? Is it the entire DNS?
    
    
    
    23) s4.5: r/to the DNSSEC/to DNSSEC
    
    
    
    24) s4.5: 1st mention of secret keys.  Ought it be defined earlier?
    
    
    
    25) s4.5.1: For question 3, if the entity is not a TA, isn’t there just one
    
    answer for the RP part of this question?
    
    
    
    26) s4.5.1: For question 5, Isn’t this subsumed by DNSSEC documents?
    
    
    
    27) s4.5.2: Bullet 2, r/n out of m/"n of m"
    
    
    
    28) s4.5.5: Point to ISO 15408:2009?
    
    
    
    29) s4.6.1: r/and the key length used to create the keys/and key lengths
    
    
    
    30) s4.8: r/liability assummed/liability asserted/
    
    
    
    31) s7: r/The sensitivity of the information protected by DNSSEC on all levels
    
       in the DNS tree will vary significantly.
    
         /The sensitivity of the information protected by DNSSEC at different tiers
    
       in the DNS tree varies significantly.
    
    
    
      r/information/information (i.e., DNS records)
    
    
    
     r/Entities must evaluate their own environment and the
    
       chain of trust originating from their Trust Anchor, the associated
    
       threats and vulnerabilities, to determine the level of risk they are
    
       willing to accept.
    
      /Each relying party must evaluate its own environment and the
    
       chain of trust originating from a Trust Anchor, the associated
    
       threats and vulnerabilities, to determine the level of risk it is
    
       willing to accept when relying on DNSSEC-protected objects.

draft-ietf-grow-diverse-bgp-path-dist

  1. Stewart Bryant: Comment [2012-07-18]:
    This document has abbreviations that do not seem to have been expanded on first
    
    use: AS, P (in the Figs), RR'
    
    
    
    "For a given destination "D" ASBR1 and ASBR2 will each have an external path P1
    
    and P2 respectively." is an assumption  not a statement as far as I can see.
  2. Benoit Claise: Discuss [2012-07-18]:
    -
    
    
    
       The need to disseminate more paths than just the best path is
    
       primarily driven by three requirements.  First is the problem of BGP
    
       oscillations [I-D.ietf-idr-route-oscillation].
    
    
    
    Searching for ietf-idr-route-oscillation, I realized that this is now RFC3345,
    
    published in 2002 !!! Have you run the idnits on this draft? This error is
    
    obviously flagged, but there are a couple of extra ones:
    
      == Unused Reference: 'RFC2119' is defined on line 843, but no explicit
    
         reference was found in the text
    
    
    
      == Unused Reference: 'RFC5226' is defined on line 853, but no explicit
    
         reference was found in the text
    
    
    
      == Unused Reference: 'RFC4984' is defined on line 898, but no explicit
    
         reference was found in the text
    
    
    
    -  "This is achieved by including as a part of the NLRI an additional
    
       four octet value called the Path Identifier."
    
    
    
    It took me a while to understand that you actually refer to
    
    draft-ietf-idr-add-paths-07 in the section 2.1
    
    Very confusing, since I read, in sequence:
    
       "This proposal does not specify any changes to the BGP protocol
    
       definition.  It does not require upgrades to provider edge or core
    
       routers nor does it need network wide upgrades.  The only upgrade
    
       required is the new functionality on the new or current route
    
       reflectors."
    
       ...
    
       "This is achieved by including as a part of the NLRI an additional
    
       four octet value called the Path Identifier."
    
    
    
    Please be explicit.
    
    
    
    - The relationship with draft-ietf-idr-add-paths-07 is unclear to me.
    
    If we have draft-ietf-idr-add-paths-07, do we still need this solution?
    
    My conclusion from the section 2 is no!
    
    It's only after reading through section 3 that I finally understood: your
    
    propose " The diverse BGP path dissemination proposal" as an alternate solution
    
    to   draft-ietf-idr-add-paths-07, right? Your draft title and abstract are very
    
    misleading. First paragraph says: As defined and widely deployed today BGP has
    
    no mechanisms to distribute alternate paths Second paragraph: This document
    
    presents an alternative mechanism for solving the problem based on the concept
    
    of parallel route reflector planes.
    
    
    
    Alternate to what? Now, I understand that it's alternate to
    
    draft-ietf-idr-add-paths-07 Please rewrite the abstract. Somehow it should
    
    extract information from the section 3 and from one of paragraphs in section
    
    2.1:
    
    
    
       While it needs to be clearly acknowledged that the add-path mechanism
    
       provides the most general way to address the problem of distributing
    
       many paths between BGP speakers, this document provides a much easier
    
       to deploy solution that requires no modification to the BGP protocol
    
       where only a few additional paths may be required.  The alternative
    
       method presented is capable of addressing critical service provider
    
       requirements for disseminating more than a single path across an AS
    
       with a significantly lower deployment cost
    
    
    
    And clearly mention the name of your proposal "The diverse BGP path
    
    dissemination proposal", which I see from time to time in the draft. Btw,
    
    should this be the document title?
  3. Benoit Claise: Comment [2012-07-18]:
    - OLD:
    
       The BGP protocol as defined today has no mechanism to distribute other
    
       then best path between its speakers.
    
    NEW:
    
       The BGP protocol as defined today has no mechanism to distribute other
    
       than best path between its speakers.
    
    
    
    - add an extra "," in the following section
    
       As it has been proven that distribution of only the best path of a
    
       route is not sufficient to meet the needs of continuously growing
    
       number of services carried over BGP, the add-paths proposal was
    
       submitted in 2002 to enable BGP to distribute more then one path.
    
    
    
    Btw, you mean http://tools.ietf.org/html/rfc3345 (which was done in 2002) in
    
    this case, why not clearly mention it?
    
    
    
    - Next paragraph mentions:
    
       The implication of this change on a BGP implementation is that it
    
       must now maintain per path, instead of per prefix, peer advertisement
    
       state to track which of the peers each path was advertised to.  This
    
       new requirement has its own memory and processing cost.  Suffice to
    
       say that it took over 9 years for some commercial BGP implementation
    
       to support the new add-path behaviour in production code, in major
    
       part due to this resource overhead.
    
    
    
    Here, the last sentence speaks about
    
    http://tools.ietf.org/html/draft-ietf-idr-add-paths-07? If yes, why not clearly
    
    mention it
    
    
    
    Same remark for
    
       The add paths protocol extensions have to be implemented by all the
    
       routers within an AS in order for the system to work correctly.
    
    
    
    -
    
       The required code modifications include enhancements such as the Fast
    
       Connectivity Restoration Using BGP Add-path
    
       [I-D.pmohapat-idr-fast-conn-restore].
    
    
    
    IS this right? Isn't it?
    
    
    
       The required code modifications can offer the foundation for enhancements
    
       such as the Fast Connectivity Restoration Using BGP Add-path
    
       [I-D.pmohapat-idr-fast-conn-restore].
    
    
    
    -
    
    4.  Multi plane route reflection
    
       The idea contained in the proposal assumes the use of route
    
       reflection within the network.  Other techniques as described in the
    
       following sections already provide means for distribution of
    
       alternate paths today.
    
    
    
    The last sentence seems to come out of the blue. At least, I don't understand
    
    why it's there.
    
    
    
    - Section 7
    
    OLD:
    
    
    
       2.  No requirement for upgrades to edge and core routers.  Backward
    
           compatible with the existing BGP deployments.
    
    
    
    NEW
    
    
    
       2.  No requirement for upgrades to edge and core routers (as required in
    
       draft-ietf-idr-add-paths-07).  Backward
    
           compatible with the existing BGP deployments.
  4. Adrian Farrel: Discuss [2012-07-19]:
    Section 3 says many of the right things, yet it is still appears to be
    
    the case that this document does compete (intention or not) with add-
    
    paths. Would you consider strengthening the text by adding something to
    
    the effect of...
    
    
    
       Provides an interim solution until the standardisation and
    
       implementation of add-paths, and until support for that function
    
       can be deployed across the network.
    
    
    
    ---
    
    
    
    Section 4
    
    
    
       Diverse path route reflectors need the new ability to calculate and
    
       propagate the Nth best path instead of the overall best path.  An
    
       implementation is encouraged to enable this new functionality on a
    
       per neighbor basis.
    
    
    
    I would like to be clear on this. As phrased "Nth best path" implies
    
    there is an ordering. "Propagate" implies that that ordering is also
    
    distributed along with the path itself.
    
    
    
    Preserving ordering over BGP routes is not so easy (blame the MED path
    
    attribute) so I wondered:
    
    
    
    - Is ordering needed or do you just need the N best paths?
    
    - If ordering is needed, how do you ensure it is propagated?
    
    
    
    This also makes me wonder whether in a multi-vendor environment there is
    
    a need for all participating routers to have the same understanding of
    
    "best". If that is the case, isn't this a document that changes on-wire
    
    behavior (viz. which paths are advertised) and needs conformance in
    
    order to make a coherent deployment? That would make it standards track
    
    (see also my comment on RFC 2119).
    
    
    
    ---
    
    
    
    I can't find a description of what happens when the primary route is
    
    withdrawn. Is there a risk that this will trigger a cascade across the
    
    planes? Suppose you have two planes. Plane 1 advertises the primary
    
    route, Plane 2, secondary. When the primary route for some destination
    
    goes unreachable (say, because its next-hop disappears from the IGP)
    
    both the Plane 1 and Plane 2 RRs come to know about it roughly at the
    
    same time, though Plane 2 may actually hear first for whatever reason.
    
    Plane 1 will advance the backup route to primary and advertise it.
    
    Plane 2 will advance the route to primary, decide there is no backup
    
    any more for it to advertise, and withdraw its route. The problem is
    
    if Plane 2 acts first and withdraws the (formerly-) backup route before
    
    Plane 1 advertises it. Could this be addressed by building in a N*K
    
    delay into Plane N routers? This doesn't seem to be addressed in the
    
    I-D, and it probably should be.
  5. Adrian Farrel: Comment [2012-07-19]:
    Section 4.3
    
    
    
       That will allow to distribute more then single best
    
       BGP path from a given route server to such IX peer.
    
    
    
    s/then/than the/
    
    
    
    Please expand IX on first use
    
    
    
    ---
    
    
    
    I assume that RFC 2119 language has not been used because this document
    
    does not define any new protocol procedures (merely config/deployment
    
    options). I am not sure whether that is the best approach since there
    
    are some key behaviors that you want implementations/deployments to
    
    adhere to in order for the behavior you are describing.
    
    
    
    If you decide to continue to not use RFC 2119 language, then you should
    
    remove the reference.
  6. Stephen Farrell: Comment [2012-07-18]:
    
    
    
    I agree with Hilarie Orman's secdir review [1] both
    
    about the difficulty of reading this and the possible
    
    security issues and would encourage the authors
    
    to consider the points she raised.
    
    
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03409.html
  7. Brian Haberman: Comment [2012-07-19]:
    I support both Adrian's and Benoit's DISCUSS points.
    
    
    
    This document was much harder to read than it had to be.  As was pointed out by
    
    Hilarie and other, there are sections of the draft that are hard to parse until
    
    they are read 2 or 3 times.  I think the document would benefit from an
    
    end-to-end grammatical review.

draft-ietf-grow-private-ip-sp-cores

  1. Benoit Claise: Comment [2012-07-13]:
    When I read in the abstract RFC1918 + loopbacks, I was immediately thinking:
    
    that's bad from a opeational/management point of view, because, in many
    
    networks, the loopback IP address is the unique router identifier in the NMS
    
    applications. Thinking some more... as long as the loopback addresses are
    
    unique, this should be fine. However, applying RFC1918 IP addresses to
    
    loopbacks is still looking for problem from an operational point of view. -
    
    Let's assume, in this world of acquisitions, that the network operator has to
    
    merge two networks, each using the same same private IP block for their
    
    respective loopbacks... he has to renumber one of the two networks. - Let's
    
    assume, in this connected world, that the network operator has to compare
    
    NetFlow/IPFIX flow records from different routers in different networks and
    
    those networks use the same private IP addresses block for their respective
    
    loopbacks... He has a problem, because, most of the time, the unique id in the
    
    collector is the source IP address of the UDP export, so the loopback. Same
    
    thing for syslog btw.
    
    
    
    I'm wondering if it would not be worth completing the section 9 "Operational
    
    and Troubleshooting issues"?
  2. Adrian Farrel: Comment [2012-07-18]:
    I have no objection to the publication of this document.
    
    
    
    It did feel to me,on reading the doument, that the problems reported are all
    
    associated with attempting to deploy a flat network using private addressing.
    
    However, the observation that one motivting factor is "core hiding" makes it
    
    reasonable to observe that the problems do not exist if proper network
    
    layereing is applied. Of course, such layering makes network operation more
    
    complex and also makes some functions (like traceroute) impossible or secret,
    
    while other functions (such as PMTUD) require cross-layer coordination.
    
    
    
    That doesn't detract from the document, but suggest that issues may be less
    
    black/white.
    
    
    
    OTOH one might note that IPv6 removes the largest "need" for private addressing
    
    and so this document should be reporting an interesting quirk of history!
  3. Brian Haberman: Discuss [2012-07-16]:
    These issues should be relatively easy to address, but please feel free to
    
    discuss them with me if you have a different point of view.
    
    
    
    1. I don't understand why Section 4 is limiting Path MTU Discovery to TCP use
    
    cases.  The referenced RFCs are applicable to other transport protocols as
    
    well.  I would suggest dropping any references to TCP in that section and have
    
    it focus on the general issues that PMTUD could/would encounter in the
    
    scenarios described.
    
    
    
    2. Section 5 makes the statement: "Scarcity of public IPv4 addresses, and the
    
    transition to IPv6, is forcing many service providers to make use of NAT." I
    
    don't believe that the transition to IPv6 is forcing ISPs to deploy NATs.  I
    
    would suggest deleting that clause.
    
    
    
    3. I was surprised to read in Section 7 that it is *uncommon* for peering
    
    relationships to be anchored on loopback addresses.  I have been told several
    
    times that this technique is quite common and allows for peering sessions to
    
    survive link/interface outages.  Is there a pointer/reference that can be added
    
    that supports this assertion?
  4. Brian Haberman: Comment [2012-07-16]:
    1. The document uses several acronyms without expansion.  For example, the
    
    introduction does not expand RIR on its first use.
    
    
    
    2. The note in the introduction could be clarified.  I don't think "stolen" is
    
    appropriate in this context.  The draft actually uses the correct term "squat",
    
    but only as an alternative.  I would suggest removing the use of "stolen" and
    
    replacing it with "squat" since addresses are not property.
    
    
    
    3. The figures, especially the one in Section 3, are hard to follow.  Would it
    
    be possible to re-work them with more/better delineation between devices?  I
    
    can provide an example if it would help.
  5. Russ Housley: Comment [2012-07-18]:
    
      Please consider the suggested changes from the Gen-ART Review by
    
      Suresh Krishnan on 16-July-2012.  The review can be found here:
    
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07609.html
  6. Barry Leiba: Discuss [2012-07-18]:
    This is a very straightforward, simple DISCUSS for an IANA issue.
    
    In Section 5, the following text makes it look like a request is being made of
    
    IANA:
    
    
    
       To address this scenario and others, "IANA-Reserved IPv4 Prefix for
    
       Shared Address Space" [RFC6598] requests a dedicated /10 address
    
       block for the purpose of Shared CGN (Carrier Grade NAT) Address
    
       Space.
    
    
    
    IANA suggests that it be changed to this, and I agree that it needs to change
    
    to make it clear that this allocation already exists, and is not a new request:
    
    
    
       To address this scenario and others, "IANA-Reserved IPv4 Prefix for
    
       Shared Address Space" [RFC6598] allocated a dedicated /10 address
    
       block for the purpose of Shared CGN (Carrier Grade NAT) Address
    
       Space: 100.64.0.0/10.
  7. Martin Stiemerling: Comment [2012-07-18]:
    I support Brian's DISCUSS point no. 1 about why only TCP is named for PMTUD in
    
    Section 4.
    
    
    
    Another point to be considered:
    
    
    
    Section 5., paragraph 1:
    
    
    
    >    Private addressing is legitimately used within many enterprise,
    
    >    corporate or government networks for internal network addressing.
    
    >    When users on the inside of the network require Internet access, they
    
    >    will typically connect through a perimeter router, firewall, or
    
    >    network proxy, that provides Network Address Translation (NAT) or
    
    >    Network Address Port Translation (NAPT) services to a public
    
    >    interface.
    
    
    
      Why not simply saying that this type of traffic passes through a NAT
    
      when heading for the public Internet. It does not matter if the NAT
    
      is implemented on a stand-alone device, a router, a set top box, etc.
    
      The current text might just cause confusion for an average reader.

draft-claise-export-application-info-in-ipfix

  1. Stewart Bryant: Comment [2012-07-17]:
    Thank you for addressing my concerns
  2. Wesley Eddy: Comment [2012-07-18]:
    As with similar "Company X's FooBar" documents, I think it is bizarre to let
    
    the boilerplate say that the IETF has consensus that this is what Cisco does.
    
    
    
    Though I am opposed to IETF work on DPI and supporting technologies like this
    
    as they are clearly hopeless and fundamentally harmful to the Internet, I have
    
    no technical arguments with this document and no objection to publishing what
    
    Cisco is doing in this regard.
  3. Adrian Farrel: Comment [2012-07-19]:
    To the AD:
    
    
    
    Could you update the ballot and approval notes to reflect the new
    
    name of the document, please.
    
    
    
    ---
    
    
    
    To the Authors / ISE:
    
    
    
    The first section could really do with having text that explains (per
    
    the title and Abstract - but in a little more detail) that this is a
    
    Cisco-proprietary extension to IPFIX.
    
    
    
    I found a very skimpy sentence in Section 2 (which made me recall that
    
    I like it when the first section of a document is the Introduction :-)
  4. Stephen Farrell: Comment [2012-05-21]:
    
    - The reference to http://www.cisco.com/ seems wonderfully
    
    vague, but unfortunately useless. What are the "Cisco
    
    systems assigned numbers"? (I agree with this bit of
    
    Stewart's discuss)
    
    
    
    - 2.1: I don't think I buy the congestion control use
    
    case. (While I don't like the security use case, I do
    
    agree others might like it.)
    
    
    
    - 4.1: is this encouraging folks to guess what IANA might
    
    allocate for IANA to act? Seems like a bad idea.o
    
    
    
    - 4.2: PANA-L* - I don't get how this works.  How can you
    
    assign selector lengths for the PANA-L* in 4.2?
    
    
    
    - section 7: I don't get how some ElementId's are assigned
    
    here already but are marked as reserved in the IANA
    
    registry.
    
    
    
    - AppA: How is section 7 of an informative document
    
    normative?
  5. Russ Housley: Discuss [2012-07-15]:
    
      In response to the Gen-ART Review by Roni Even the authors created
    
      Appendix C, which references [CISCO-APPLICATION-REGISTRY].  We have
    
      been waiting for the referenced web page to appear since 29 May 2012.
    
      I do not think that the IESG should approve the document to a web page
    
      that cannot be reviewed.  Please remove Appendix C and the reference.
  6. Barry Leiba: Comment [2012-07-19]:
    I agree with the comments that the boilerplate for this sort of document is
    
    odd.  I think we need to look at the choices we have for what to say at the
    
    beginnings of documents, and make sure there's a good, standard option for
    
    "this is not a consensus document; we're just putting it out for information." 
    
    Or maybe this says that this should have gone through the ISE.
    
    
    
    In any case, I have no objection to publishing this, so here we go.
  7. Robert Sparks: Discuss [2012-07-18]:
    (Hoping this is easy to clear). The header/boilerplate seems to be what would
    
    happen normally following RFC5741. What's the EDITOR NOTES: block there for?
    
    Are there clear instructions to remove it somewhere?
  8. Martin Stiemerling: Discuss [2012-07-19]:
    Sorry for this late discuss but what about user privacy?
    
    (I'm not a security AD, but I wonder anyhow)
    
    
    
    The document says
    
         Today service providers and network administrators are
    
          looking for visibility into the packet content rather than
    
          just the packet header.
    
    
    
    When talking about packet content and identifying applications used,  we are
    
    already at the door sill to see what individuals are doing in the network.
    
    
    
    I've read the Security Considerations to see if the privacy aspects are being
    
    disucssed there and was very much disappointed. Especially also that the
    
    reference RFC 5101 is also not discussing user privacy.
  9. Martin Stiemerling: Comment [2012-07-19]:
    I am also wondering about the boiler plate, such as Wes does. Why is this
    
    presenting IETF consensus if it is a company's protocol only?

draft-melnikov-smtp-priority-tunneling

  1. Adrian Farrel: Comment [2012-07-18]:
    I have no objection to the publication of this document, and welcome that it is
    
    Experimental.
    
    
    
    As with many Experimental documents I review, I would like the Abstract to note
    
    the Experimental status (as, for example, is done in the first line of the
    
    Introduction). I should also like to see a little more scoping of the
    
    Experiment: - why it is experimental - what nodes participate in the experiment
    
    - how the experiment is constrained - how the experiment will be judged
    
    
    
    It is not mandatory to add such text (hence this is not a Discuss), but I think
    
    it really helps people work out how to work with the document.
  2. Stephen Farrell: Comment [2012-07-16]:
    
    
    
    - Section 7, 1st para: How would one use S/MIME to sign the
    
    MT-Priority header field? You'd have to encapsulate the message
    
    wouldn't you? I think you could omit mention of S/MIME here.
    
    
    
    - Section 7, 1st para (again:-): DKIM doesn't allow you to know
    
    who put this header on, just who signed it (if its included in
    
    the signature). So I think what you want to say is something
    
    like "DKIM signing allows a recipient to verify that the
    
    specified priority value was present when the message was
    
    signed, and to verify who signed the message." But the signer
    
    might not be the one that "generated" the header.
    
    
    
    - Same section: Calling for an MUA to use DKIM is a bit of a
    
    stretch, but would I guess work, though the key mgmt isn't very
    
    well-defined for that use-case really since you end up with
    
    per-user keys in the DNS, or have to share private keys.
  3. Russ Housley: Discuss [2012-07-18]:
    
      Based on the discussion following the posting of the Gen-ART Review
    
      by Martin Thomson on 8-June-2012, it seems that there is an
    
      inconsistency that needs to be resolved:
    
      >
    
      > But now that I am looking at the two sections ("Security
    
      > Considerations" and "Relay of messages to non-conforming SMTP
    
      > servers"), they might be out of sync as far as requirements are
    
      > concerned. So I need to tweak one or both of them to match.
  4. Barry Leiba: Comment [2012-07-09]:
    As I noted in the shepherd writeup, I have some concern about the broader
    
    applicability of this as a standard, given the trade-offs the proponents have
    
    made.  That said, some of them had to be made, and there is value in
    
    implementing features from proprietary email systems in standardized ways on
    
    the open Internet.  There does seem to be consensus that it's worth trying this
    
    out, and that it's not terribly unsafe to do so.
    
    
    
    The tunneling of the PRIORITY value through non-conforming MTAs by turning it
    
    into a message header field (MT-Priority) and then back again is a problematic
    
    technique, but is an important capability for those who need and intend to
    
    implement the smtp-priority extension.  It creates a trust issue, wherein a
    
    message containing MT-Priority could be originated with a Message Submission
    
    Agent that does not know about this extension, and when the message hits a
    
    Message Transfer Agent that does support this, the header field will be turned
    
    back into a valid PRIORITY value, on the unwarranted assumption that it was
    
    authorized.  Intermediate MTAs have no way to distinguish this situation from
    
    one where the field was tunneled legitimately.
    
    
    
    The counter-argument is that the use case for this specification involves
    
    out-of-band trust relationships, and that such situations will be known and
    
    dealt with.  Only by experimenting with it will we see how (or if) it can
    
    extend to other use cases where such trust relationships aren't as clean.
  5. Pete Resnick: Discuss [2012-07-19]:
    Between Adrian's comment and Barry's, I am no longer convinced that
    
    Experimental is the correct status for this document (and I kick myself for not
    
    noticing this earlier on my own). I'm considering Informational. I'd like to
    
    discuss this issue, and not only with myself.

draft-krishnan-nomcom-tools

  1. Stewart Bryant: Discuss [2012-07-16]:
    This is basically a sound document, but there are some details that need
    
    attention. Once these are addressed I will be happy to vote yes.
    
    
    
    =====
    
    
    
    Sec-001 and Sec-005 look the same
    
    
    
    =====
    
    
    
    This information can only be accessed by the members of the Nomcom.
    
    
    
    Does the above mean voting members, voting members + chair.....?
    
    
    
    =====
    
    
    
    AD-004: The tool MUST allow to view a list of all nominees along
    
          with their accepance or decline status.
    
    
    
    Must allow who?
    
    
    
    =====
    
    
    
    AD-005: The tool MUST allow the reporting of accepance or decline
    
          status both per nominee as well as per open position.
    
    
    
    Reporting to who?
    
    
    
    =====
    
    
    
    The nominees fill in a questionnaire for each of the positions for
    
       which they accept a nomination.
    
    
    
    .. and does what with it? Sends an email, posts it on the web site
    
    completes it on the web site?
    
    
    
    =====
    
    
    
    FB-005: All email received on the Nomcom mailing list MUST be
    
          archived.
    
    
    
    For what period, and who has access to the archive?
    
    
    
    =====
  2. Stewart Bryant: Comment [2012-07-16]:
    
    AUTH-003: The tool MUST allow the secretariat to input an email
    
          address to be provided the Nomcom chair role and a list of email
    
          addresses to be provided the Nomcom member role.
    
    
    
    The above requirement does not read correctly - possibly missing some "by"s
    
    
    
    =====
    
    
    
    The filled in questionnaires are
    
          received as emails to the Nomcom mailing list.
    
    
    
    Surely they are sent as emails
    
    
    
    =====
  3. Benoit Claise: Comment [2012-07-17]:
    I support this document. However, I have some comments.
    
    
    
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    - When I read:
    
       "The users of the tools may have different privileges based on their role.
    
       The tool needs to support at least three levels of access:Community
    
       member, Nomcom member, Nomcom chair.
    
    
    
    I don't understand the "may".
    
    If you create different levels, isn't because the different levels "must" have
    
    different privileges? From there, I was wondering: what are the different
    
    privileges based on the role? I was hoping to find a definition of Nomcom
    
    member and/or Nomcom chair in one of the nomcom RFCs (RFC3777, RFC5078,
    
    RFC5633, RFC5680), along with their role definition. However, it doesn't seem
    
    to exist. Disclaimer: I have not seen
    
    https://www.ietf.org/group/nomcom/2011/private/, so it's difficult to
    
    understand if we miss requirements about the role versus privileges, or if this
    
    falls into the META-001 requirement.
    
    
    
     - "The tool needs to support at least three levels of access:Community
    
       member, Nomcom member, Nomcom chair.
    
    
    
       ...
    
    
    
       o  AUTH-003: The tool MUST allow the secretariat to input an email
    
          address to be provided the Nomcom chair role and a list of email
    
          addresses to be provided the Nomcom member role."
    
    
    
    So which of the three levels has the Secretariat? Nomcom member?
    
    Or do you need a fourth role just for Secretariat/Tools admin?
    
    
    
    Along the same lines:
    
       o  SEC-005: The data accumulated by the tool MUST be stored in a
    
          fashion that prevents accidental exposure of the data to people
    
          who administer the server(s) on which the data is stored.
    
    
    
    Do you consider the Secretariat part of the "people who administer the
    
    server(s)"? I guess not. So how many roles do you need at the end?
    
    
    
    Editorial comments
    
    - OLD:
    
    
    
    QR-005: Like all other correspondance on the Nomcom mailing list,
    
          the questionnaires MUST be encrypted by the Nomcom public key
    
          before being stored.
    
    
    
    NEW:
    
    QR-005: Like all other correspondance on the Nomcom mailing list,
    
          the filled in questionnaires MUST be encrypted by the Nomcom public key
    
          before being stored.
  4. Ralph Droms: Discuss [2012-07-17]:
    I see some of these issues have been noted by other ADs.
    
    
    
    1. (cleared)
    
    
    
    2. What is the difference between requirements SEC-000 and SEC-005;
    
       what is the "data accumulated by the tool"?
    
    
    
    3. FB-001 needs to have a requirement for annoymous feedback, and for
    
       tracking the submitter of non-anonymous feedback.
    
    
    
    4. In FB-006, should that read "copy" rather than "move"?
  5. Ralph Droms: Comment [2012-07-17]:
    I see some of these comments have been noted by other ADs.
    
    
    
    1. In NOM-00[12], what are the "Public Nomcom tool" and the "Private
    
       Nomcom tool"?
    
    
    
    2. In NOM-002, is the "originator of the nomination" the Nomcom member
    
       who entered the nomination?  Is this information recorded for
    
       nominations from the public as well?
    
    
    
    3. I don't understand AD-002.  Aren't the responses from the nominees
    
       restricted to "accept" or "decline"?
    
    
    
    4. AD-004: "MUST allow to view" seems to be missing a word between
    
       "allow" and "to".
    
    
    
    5. In FB-002, who is "the originator of the feedback"?
    
    
    
    6. Section 9 is not written in the form of requirements.  The first
    
       two sentences seem to be a duplicate of text from section 3 (which
    
       was also not written in the form of a requirement).
    
    
    
    7. What about extensions for secure, audited voting?
  6. Adrian Farrel: Comment [2012-07-19]:
    I think it is important to hurry this document through if we are
    
    serious about developing tools to make the work of NomCom less
    
    arduous. But I also think it is important to get the specification
    
    right so that the tools developed do what is required wasting neither
    
    time nor effort. In view of this, I support a number of the existing
    
    Discusses that focus on the precision of the requirements.
    
    
    
    ---
    
    
    
    We should try to learn from the tools database issues that arose in
    
    NomCom 2011. How can we ensure that the feedback that has been entered
    
    remains available to the NomCom and does not have to be reconstructed
    
    or retrieved by special action?
    
    
    
    ---
    
    
    
    Section 8
    
    
    
    IIRC the current tools do not allow an individual to revist the feedback
    
    that they have already entered for a candidate. Although it is possible
    
    to request an email copy of the feedback at the time it is entered, it
    
    is not possible to recall the feedback through the web page. Such a
    
    feature would be useful as a reminder before an interview, for
    
    correlation of feedback against multiple candidates, and to allow
    
    updates to feedback as new thoughts arise.
    
    
    
    It would be nice to add this feature.
  7. Stephen Farrell: Comment [2012-07-16]:
    
    - General question and a near-discuss: What, if anything, should
    
    happen to the stored/archived information after the nomcom has
    
    done its work? And if something should happen, (e.g. deletion)
    
    when ought that happen? This may all be in some RFC, but I just
    
    don't know and I could see various good and bad answers being
    
    possible here. 3777 says that: "The nominating committee should
    
    archive the information it has collected or produced for a
    
    period of time not to exceed its term." I don't know what's
    
    actually done now, but could imagine that tools might make
    
    it better or worse.
    
    
    
    - Section 2, will those URLs containing 2011 remain good for
    
    sufficiently long to be useful? Maybe s/2011/2012/ at least.
    
    
    
    - Section 4, "should be stored using an encrypted cookie" is
    
    wrong. Cookies may disappear (e.g. in http/2.0) and other better
    
    technologies might come along.
    
    
    
    - Section 4, I think you need to say somewhere that each nomcom
    
    MUST use a different key pair.
    
    
    
    - Section 4, s/using the procedure/for example, using the
    
    procedure/ would be better.
    
    
    
    - 2119 and 3777 should be referenced somewhere in the
    
    text I guess.
    
    
    
    - Section 4, I think you need to say somewhere that each nomcom
    
    MUST use a different key pair.
    
    
    
    - Section 4, s/using the procedure/for example, using the
    
    procedure/ would be better.
  8. Brian Haberman: Comment [2012-07-12]:
    I support the publication of this document and only have the following,
    
    non-blocking, comments:
    
    
    
    1. The last sentence of the Introduction is missing a period.
    
    
    
    2. Why does the security section start numbering at 000 and all the other
    
    sections start at 001?
    
    
    
    3. With AD-006, is there a need to allow for the specification of time windows
    
    when generating statistics?
    
    
    
    4. AD-002 refers to "Acceptances and declines".  Is there a reason for the
    
    capitalization of "Acceptances", but not of "declines"?
    
    
    
    5. The QR requirements also mix and match capitalization of "Questionnaires".
    
    
    
    6. I support Barry's feedback on the use of 2119 keywords when referring to the
    
    management of the key and encrypted cookie.
  9. Barry Leiba: Comment [2012-06-13]:
    Substantive comments; these are non-blocking, but please consider them
    
    seriously, and feel free to chat with me about them:
    
    
    
    Section 3
    
    Is there really no need for a fourth "Nomcom advisor or liaison" role?
    
    
    
    Sec-004
    
    The MUST in the second sentence is silly: this isn't a normative command, but a
    
    simple statement, "This key will be used to decrypt...."  But in the third
    
    sentence, shouldn't it be, "Once entered, this key MUST be stored using an
    
    encrypted cookie?", rather than "should be stored"?
    
    
    
    Section 6
    
    It's not clear to me why there's a difference between a community member
    
    entering a nomination and a Nomcom member doing it.  Maybe you can explain that
    
    a little more, briefly.
    
    
    
    QR-002 & QR-006
    
    Please make it clearer what the substantive difference is between these two.
    
    
    
    ========
    
    Other comments; no need to respond to these. Take them or modify them
    
    as you please:
    
    
    
    Auth-003
    
    Maybe it's just me, but I found that I had to read the "to be provided" bits a
    
    few times before I correctly parsed them.  "To be given" or "to get" sounds
    
    better to me.
    
    
    
    AD-004
    
    I don't think "allow <infinitive>" is proper usage, though it's common.
    
     Anyway, to make it parallel to the other items, how about, "allow the viewing
    
    of a list..."?
    
    
    
    Appendix A
    
    Typo "pait" -> "pair"
  10. Martin Stiemerling: Discuss [2012-07-17]:
    Most of the issues are already covered by other COMMENTs raised about this
    
    draft, but:
    
    
    
    Section 3., paragraph 2:
    
    
    
    >    o  AUTH-001: The tool MUST allow the members of the community to
    
    >       login with their existing datatracker.ietf.org credentials.
    
    >    o  AUTH-002: The tool MUST allow the members of the community to
    
    >       create a new login with an automated system.  The system MUST
    
    >       verify that e-mail address used for creating the login.
    
    
    
      What does 'verify that e-mail address' mean? Verify for correctness
    
      of the syntax? I guess not. This could be clarified to 'MUST verify
    
      that the email address is in existence'.
    
    
    
    Section 5., paragraph 2:
    
    
    
    >    o  NOM-001: The tool MUST allow the members of the community to enter
    
    >       nominations into the Public Nomcom tool.
    
    >    o  NOM-002: The tool MUST allow the members of the Nomcom to enter
    
    >       nominations into the Private Nomcom tool.  The tool MUST allow the
    
    >       Nomcom member to optionally enter information about the originator
    
    >       of the nomination.  The tool MUST record the identity of the
    
    >       originator of the nomination for audit purposes.
    
    
    
      Does the second MUST about the identity also apply to NOM-001?
    
     And isn't a further NOM- requirement?
    
    
    
    >    o  FB-006: The tool MUST allow the Nomcom chair to manually move any
    
    >       of the archived mails into the feedback section of one or more
    
    >       nominees for one or more open positions.  This is required because
    
    >       a single email may contain feedback concerning more than one
    
    >       nominee or more than one open position.
    
    
    
      Moving an email implies removing it from the archive? Or is it
    
      meant to say "copy"?
    
    
    
    Section 9., paragraph 1:
    
    
    
    >    The tool must authenticate all users and must allow classifying
    
    >    logins into 3 roles.  Nomcom chair, Nomcom member and community
    
    >    member.  All communications to/from the Nomcom and among the members
    
    >    of the Nomcom must be stored in an encrypted form.
    
    
    
      What about a role 'liaison'? This role seems to be distinct from
    
      the other roles.
  11. Martin Stiemerling: Comment [2012-07-17]:
    **Editorals:
    
    
    
    Section 1., paragraph 1:
    
    
    
    >    The IETF Nominations Committee (Nomcom) is a body that selects
    
    >    candidates for the open IESG, IAB and IAOC positions.  There is a
    
    >    need for a set of tools to aid the Nomcom to operate efficiently.
    
    >    This document lays out a few requirements for such a tool
    
    
    
      s/a few requirements/a set of requirements/
    
     s/tool/tool./
    
    
    
    >    o  AD-005: The tool MUST allow the reporting of accepance or decline
    
    >       status both per nominee as well as per open position.
    
    
    
      s/accepance/acceptance/
    
    
    
    >    o  QR-004: The tool MUST keep track of the questionnaire receipt
    
    >       status for the nominees.  The filled in questionnaires are
    
    >       received as emails to the Nomcom mailing list.
    
    
    
      Sent to the Nomcom mailing list, isn't it?
  12. Sean Turner: Discuss [2012-07-17]:
    Okay so I know it's just an example in Appendix A, but I bet everybody will use
    
    it.  Therefore, we'd better make sure to specify SHA-256 because SHA-1 is the
    
    default (more on that in the comments).
    
    
    
    Does the key you just made need to be password protected?  The examples don't
    
    show it being encrypted and I don't turn PBE on in the one-step command.  If it
    
    is supposed to be encrypted let me know and we can tweak the commands.
  13. Sean Turner: Comment [2012-07-17]:
    1) AUTH-002: should you be explicit about it being datatracker.ietf.org
    
    identity?  i.e.,:
    
    
    
    o  AUTH-002: The tool MUST allow the members of the community to
    
        create a new datatracker.ietf.org login with an automated system.
    
        The system MUST verify that e-mail address used for creating the login.
    
    
    
    It's not another kind of login is it?
    
    
    
    2) AUTH-003: Do certs get made for the nomcom email address and are those email
    
    addresses provided certificates to encrypt email?
    
    
    
    3) s9: This is about the noncom chair, but shouldn't we also warn that the
    
    nomcom chair better keep that private key private!  Shoul
    
    
    
    5) A couple on Appendix A
    
    
    
    a) openssl will put the generated key in the file with the -out command so I'm
    
    not sure why you need "| tee".
    
    
    
    b) It'll do it all in one command :) (provided below)
    
    
    
    c) We need to specify SHA-256 because SHA-1 is the default :(
    
    
    
    d) hate it that we're not following recommendations and including the right
    
    bits  in the right places in the certs.  We could use a .cnf file to fix that
    
    (one included).
    
    
    
    e) Should the lifetime of the cert be 2 years because that's how long the
    
    commitment is?
    
    
    
    f) not sure why you did the -pubout command (#2) if the tool is just going to
    
    extract it.
    
    
    
    g) what is this key used for?  Is it just TLS connections or is it also data at
    
    rest (answer changes the key usages)?  I assumed it was TLS and data at rest:
    
    hence EKU: clientAuth/serverAuth and KU:
    
    digitalSignature/keyEncipherment/dataEncipherment.  I omitted keyCertSign and
    
    cRLSign bits because we're not generating additional certs.
    
    
    
    h) openssl is phasing out genrsa with genpkey so if you're not going to go for
    
    the one stop command should probably add:
    
    
    
       openssl genpkey -algorithm RSA -out rsakey2.pem \
    
               -pkeyopt rsa_keygen_bits:2048
    
    
    
    Here's the nomcom-config.cnf file to prompt the chair for the name, put the
    
    email in the right place (yes they'll have to set the address), and include the
    
    correct extensions (we can debate which ones those are).
    
    
    
    *****BEGIN FILE*****
    
    [ req ]
    
    distinguished_name = req_distinguished_name
    
    string_mask        = utf8only
    
    x509_extensions    = ss_v3_ca
    
    
    
    [ req_distinguished_name ]
    
    commonName           = Common Name (e.g., NomcomYY)
    
    commonName_deafault  = Nomcom12
    
    
    
    [ ss_v3_ca ]
    
    
    
    subjectKeyIdentifier = hash
    
    keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
    
    basicConstraints = critical, CA:true
    
    subjectAltName = email:nomcom12@ietf.org
    
    extendedKeyUsage= clientAuth,serverAuth
    
    
    
    # modify the email address to match the year.
    
    
    
    *****END FILE*****
    
    
    
    One step command:
    
    
    
      openssl req -config nomcom-config.cnf -x509 -new -newkey rsa:2048 \\
    
              -sha256 -days 730 -nodes -keyout publicKey.pem \\
    
              -out nomcom12.cert

draft-hoffman-tao-as-web-page

  1. Benoit Claise: Comment [2012-07-13]:
    My four points are not really a DISCUSS, but I really would like to see it
    
    addressed, or at least discussed
    
    
    
    1. This document has two parts, a correctly explained in the Introduction
    
    section.
    
        - it explains that the "Tao of the IETF", which has been published as a
    
        series of RFCs in the past, is now published as a web page. -. it explains
    
        the new procedure. "This document contains the procedure agreed to by the
    
        IESG"
    
    
    
    My issue is: The abstract only contains the first part 1.
    
    Here is a proposal:
    
    OLD
    
    
    
       This document describes how the "Tao of the IETF", which has been
    
       published as a series of RFCs in the past, will instead be published
    
       as a web page.
    
    
    
    NEW
    
    
    
       This document describes how the "Tao of the IETF", which has been
    
       published as a series of RFCs in the past, is instead published
    
       as a web page. Furthermore, this document contains the procedure for
    
       publishing and editing the Tao
    
    
    
    2. Why do you always use the future tense in the draft?
    
      - "This document describes how the "Tao of the IETF", which has been
    
       published as a series of RFCs in the past, will instead be published
    
       as a web page."
    
     - "The Tao will be published at <http://www.ietf.org/tao.html>" (note: it's
    
     done right in the security considerations section - etc...
    
    Specifically for the section 2, the procedure should really use the present
    
    tense. OLD:
    
    
    
     The Tao will be edited by one person who is chosen by the IESG.
    
    
    
    NEW
    
    
    
     The Tao is edited by one person who is chosen by the IESG.
    
    
    
    3. I would make sense to set up the mailing in advance and mentioned it in draft
    
    
    
       The Tao will be edited by one person who is chosen by the IESG.
    
       Suggestions for changes to the Tao will be discussed on an open, Tao-
    
       specific mailing list.
    
    
    
    4.
    
    
    
       Each version of the Tao will have a visible timestamp near the
    
       beginning of the document.  All published versions will be archived
    
       using URLs of the form
    
       <http://www.ietf.org/tao-archive/tao-YYYYMMDD.html>.
    
    
    
    If there is right now http://www.ietf.org/tao-archive/tao-20120713.html, how do
    
    I know the date of the previous version? I guess that the
    
    http://www.ietf.org/tao-archive/ directory will list all the entries, right? If
    
    this is the case, please mention it in the draft
  2. Adrian Farrel: Discuss [2012-07-18]:
    I support the publication of this document. Before moving to a "Yes"
    
    ballot, I would like to discuss how translations that are produced
    
    from time to time will be made available and archived
  3. Adrian Farrel: Comment [2012-07-18]:
    Unclear to me why the document needs to limit the edit team to exactly one
    
    person for all time.  Suggest "one or more people as designated by the IESG"
  4. Barry Leiba: Comment [2012-06-15]:
    Gotta love the Security Considerations section.  :-)
  5. Martin Stiemerling: Comment [2012-07-16]:
    The draft says in Section 2 "is based on the last Internet-Draft that was meant
    
    to replace". Should we add, just for completeness, an informational reference
    
    to this draft?
    
    
    
    Otherwise, this draft might be hard to spot.
    
    
    
    However, this might be only of interest to archaeologists...