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
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
3.3.2 Returning Items
1306 EDT break
1311 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1339 EDT Adjourned
(at 2012-07-19 07:31:29 PDT)
draft-sakane-dhc-dhcpv6-kdc-option
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.
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.
I agree with Barry's concerns. Please address them.
[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!
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
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.
Agree with Russ that this document should be INFORMATIONAL
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.
====
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?
(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
- 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.
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)?
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.
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.
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.
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.
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>
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/
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?
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
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? =======
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.
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.
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
- 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
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.
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.
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.
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?
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.
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.
In full support of Barry's point on Section 3.1.
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?
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
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.
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.
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.
Agree with Barry and Sean. I hope (expect) to see this document back on the IESG agenda soon moving to Internet Standard.
I had the same question as Sean.
I'm fine with this document, but I have to second Barry's comment about Appendix A.
Thanks for addressing my discuss.
draft-ietf-abfab-gss-eap
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.
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
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.
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/
I agree with Barry that a discussion is needed as to why an IANA registry cannot capture the necessary information.
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.
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.
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.
I support Pete's suggestion to make this standards track.
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
It is entirely unimportant, but I think most if not all references could be Informational rather than Normative.
A nit: you've misspelled "Hellman" (as "Hellmen") in the Introduction.
draft-ietf-appsawg-received-state
draft-ietf-pkix-caa
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.
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?
- 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.
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?
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.
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.
[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.
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))
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
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.
- 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.)
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.
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
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.
- 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?
[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.)
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).
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.
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?
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
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
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.
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
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.
Consider explicitly calling out that padding (=) is not included when base64url-ing.
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?
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
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
- 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".
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.
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?
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
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]"
- 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
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
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.
- 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;-)
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
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.)
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
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.
- 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.
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.
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
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
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
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.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.)
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.
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.
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.
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?
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
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.
-
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?
- 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.
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.
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.
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
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
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"?
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!
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?
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.
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
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.
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
Thank you for addressing my concerns
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.
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 :-)
- 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?
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.
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.
(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?
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.
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
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.
- 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.
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.
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.
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
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?
=====
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
=====
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.
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"?
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?
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.
- 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.
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.
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"
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.
**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?
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.
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
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
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
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"
Gotta love the Security Considerations section. :-)
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...