IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-12-18. 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: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
Telechat:
Telechat:
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
1206 EDT no break
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::
7. Agenda Working Group News
Amy: will be on winter break; Cindy on vacation Saturday, I'll be around Monday and Tuesday, sporadically checking email after that
1253 EDT entered Executive Session
(at 2014-12-18 07:30:03 PST)
draft-ietf-mpls-tp-te-mib
Thanks for addressing my Comment.
The security considerations doesn't appear to match the guidance for MIBs. ([1] that may possibly still have an update to come, not sure.) I think Benoit is onto this as well so I'll leave it to him as he knows MIBs better. [1] http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
6.1 and 10: Maybe this is crystal clear in the MPLS and SNMP communities, and if it is you can ignore this comment, but "alphabetic character" is ambiguous. You probably mean "ASCII alphabetic character", and you could simply make the substitution throughout if you like (and reference RFC 20 is you were feeling especially pedantic), but if there is no chance for misinterpretation, I certainly won't stand on ceremony.
One easy to fix DISCUSS. As noted by other IESG members, the Security Considerations don't match the Security Guidelines for IETF MIB Modules at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security
I know that this MIB was the source of much debate. Thanks for this paragraph: At the time of writing, SNMP SET is no longer recommended as a way to configure MPLS networks as was described in [RFC3812]. However, since the MIB modules specified in this document extend and are intended to work in parallel with the MIB modules for MPLS specified in [RFC3812], certain objects defined here are specified with MAX-ACCESS of read-write or read-create so that specifications of the base tables in [RFC3812] and the extensions in this document are consistent. Although the examples described in Section 9 specify means to configure MPLS-TP tunnels in a similar way to the examples in [RFC3812], this should be seen as indicating how the MIB values would be returned in the specified circumstances having been configured by alternative means.
I realize the security considerations might get updated based on comments from Stephen/Benoit, but wanted to ask about this in case this text stays in the document: "When MIB is used to configure ICC_Operator_ID, as specified in [RFC6370], it should be considered sensitive operation. Hence proper protection should be taken to allow configuration via SET operation in order to ensure its purpose of providing globally unique MPLS-TP identifiers." This is a little confusing for a number of reasons. ICC_Operator_ID does not appear to be specified in RFC 6370, but rather in RFC 6923. Global_ID is specified in RFC 6370. Was this text meant to apply to both? Also, it's not clear why the configuration of ICC_Operator_ID "should be considered a sensitive operation." Is it because failing to use a unique ICC_Operator_ID can cause operational problems (as described in RFC 6370 for Global_ID)? Isn't uniqueness guaranteed in the way that both ICC_Operator_IDs and Global_IDs themselves are generated, such that the only real risk with the MIB is that these IDs would be somehow transformed from their originals to no longer be unique? Or are they sensitive for some other reason not related to uniqueness?
draft-ietf-json-text-sequence
I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by the following text in the document: Multiple consecutive RS octets do not denote empty sequence elements between them, and can be ignored. The concern I have is that this document appears to suggest that a large dataset can be transferred as a series of json text sequences. But nowhere in the document (that I noticed) is it explained how each chunk of text is identified. It could be that they do not need to be identified: that each chunk stands alone. But suppose you are transferring array elements, rather than database tuples. In order to avoid a mis-count, it would have to be the case that each tuple contains the index of the array element that it represents. I suspect that the intention is actually that these sequences never be used this way, but it would be nice to state that explicitly, e.g. something like this: This document does not define a mechanism for reliably identifying text sequence by position (for example, when sending individual elements of an array as unique text sequences. Each json text sequence should therefore contain sufficient information that it is meaningful regardless of the order in which it appears in a stream of text sequences.
I see others have noticed the glaring typo (0x1E for LF) in the abstract...
- abstract: 2nd 0x1E should be 0x0A I guess. That really needs fixing so could well be a DISCUSS but is probably so obvious it'll happen without that:-) But let me know if you prefer this be a DISCUSS for tracking purposes. - 2.1 doesn't say anything about 0x00 which often creates security issues. Worth a note? Not sure myself. - 2.2: thanks for the ctrl-^ info - that's good. Would it be worth adding that in e.g. vim/vi you should precede that ctrl-^ with ctrl-v so as to get the right value into your file? - 2.3: I think SHOULD NOT abort is too strong - did the wg consider saying they SHOULD or MAY abort and giving the log example as a counter example? It just seems safer to me if the default behaviour is to abort. However, I'm not that certain of this point, so this isn't a discuss. - section 3: 2nd sentence, I think what you really should be saying is that parsing one of these does not necessarily give you a good input to a MAC or signature verification process as you might or might not still have canonicalisation issues. - section 3: I think you ought mention the potential here for careless code to be vulnerable to buffer overruns. We've seen that too often to ignore it I'd argue. - Most of the above plus a few others are also noted in the secdir review [1]. I'm sure the author/shepherd/AD will engage with the reviewer there too. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html
Section 2.4.: The logic for having a terminator character here seems pretty fishy to me. Can you explain the scenario in which this setup actually results in truncated texts being detected? What is the piece of software that recognizes the truncation and chooses to omit the terminator? It seems like in the obvious design (source of JSON texts feeding into sequence encoder), you just end up with (RS <truncated-JSON> LF) anyway. In order for this not to be the case, you need to have something in front of the sequence encoder that recognizes truncation and signals it to the encoder Section 2.4.: If you're going to have a terminator character, why 0x0A in particular? That character is valid in JSON texts, so using that as a terminator requires special processing on the JSON texts. As with the above, this seems to require an architecture in which the source of JSON texts cannot be independent of the sequence encoder (which kind of defeats the purpose of this supposedly lightweight sequence encoding).
Section 2.2.: "textm"
Thanks for addressing the OPS-DIR review in a timely manner.
I've asked that the media type registration request be posted to the media-types@iana.org list for comment. That's been done, and there's been a little discussion that's resulted in some suggestions for a couple of minor changes, but nothing major. I consider this point cleared, knowing that the minor changes are coming.
draft-ietf-opsawg-capwap-hybridmac
Does the abstract really need to be as long as it is? Wouldn't it be sufficient to say something like this? The CAPWAP protocol binding for IEEE 802.11 defines two MAC modes for IEEE 802.11 WTP: Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions are not clearly defined. This leads to interoperability issues, especially when the Access Controller (AC) and Wireless Transmission Point (WTP) come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC. I think this is sufficient information for people to figure out what the purpose of the document is, and then people who are interested in the stated problem will read the document. The other information in the abstract seems unnecessary, and increases the workload of the reader who is deciding whether or not the document is something they need to read based on the abstract.
- intro, last para: Figure 1's last row says "WTP" in the Local MAC column, but the text here implies that it should say AC - what am I getting wrong? - sec cons. saying WAP and AC messages "is encrypted" is not quite what you want - I think you need to say that those messages have origin authentication and data integrity (which they should have if "encrypted" properly, and if they're not that not this doc's fault).
Thank you for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05260.html
draft-ietf-ppsp-peer-protocol
In this text:
3. Messages
In general, no error codes or responses are used in the protocol;
absence of any response indicates an error.
Is there accurate qualifier more narrow than "in general" that you could
substitute? In a quick scan, the only other instances of "error" are "ICMP
error", so maybe you don't need a qualifier at all?
In this text:
3.1. HANDSHAKE
After the handshakes are exchanged, the initiator knows that the peer
really responds. Hence, the second datagram the initiator sends MAY
already contain some heavy payload, e.g. DATA messages. To minimize
the number of initialization round-trips, the first two datagrams
exchanged MAY also contain some minor payload, e.g. HAVE messages to
indicate the current progress of a peer or a REQUEST (see
Section 3.7), but MUST NOT include any DATA message.
This was difficult for me to parse, and the words "heavy" and "minor" didn't
help me understand. Is this saying something like "Peers don't include DATA
messages in payloads they send unless they've akwa successfully exchanged
messages"? If that's not what's meant, is there a list of "heavy" and "monor"
messages? (Obviously, I don't think the MAYs are 2119 MAYs because they are so
imprecise, but that's another story)
I should also mention that "heavy" appears 10 times in the specification, and I
don't think it's ever defined. Is this a term famliar with those schooled in
the art?
In this text:
3.2. HAVE
In particular, whenever a receiving peer P has successfully checked
the integrity of a chunk, or interval of chunks, it SHOULD send a
^^^^^^
HAVE message to all peers Q1..Qn it wants to interact with in the
near future. A policy in peer P determines when the HAVE is sent. P
may sent it directly, or peer P may wait until either it has other
data to sent to Qi, or until it has received and checked multiple
chunks.
This wasn't clear to me. I'm not understanding why a SHOULD is appropriate, but
I suspect I shouldn't be askig a 2119 question, because this is tangled between
"send a HAVE to the peers you want to interact with in the near future" and "if
you don't want to interact with a specific peer in the near future, you can
wait to send a HAVE". Is that even close?
In this text:
3.4. ACK
ACK messages MUST be sent to acknowledge received chunks if PPSPP is
run over an unreliable transport protocol. ACK messages MAY be sent
if a reliable transport protocol is used. In the former case, a
receiving peer that has successfully checked the integrity of a
chunk, or interval of chunks C MUST send an ACK message containing a
chunk specification for C. As LEDBAT is used, an ACK message MUST
contain the one-way delay, computed from the peer's current system
time received in the DATA message. A peer MAY delay sending ACK
messages as defined in the LEDBAT specification.
(I emphasize that this is a question, not even a comment) How hard did the
working group fight to pick a single style of transport protocol for PPSPP,
rather than support multiple styles that don't use the same state machine? If
that decision got good discussion, fine, but I wanted to ask because support
for both reliable and ureliable transport adds complexity, and I've seen
working groups that tried to do transport-independent protocols only because
they thought that's what the ADs expected.
In this text:
5.3. The Atomic Datagram Principle
As explained above, a datagram consists of a sequence of messages.
Ideally, every datagram sent must be independent of other datagrams,
so each datagram SHOULD be processed separately and a loss of one
datagram must not disrupt the flow of datagrams between two peers.
Thus, as a datagram carries zero or more messages, neither messages
nor message interdependencies SHOULD span over multiple datagrams.
This principle implies that as any chunk is verified using its uncle
hashes the necessary hashes SHOULD be put into the same datagram as
the chunk's data. If this is not possible because of a limitation on
datagram size, the necessary hashes MUST be sent first in one or more
datagrams. As a general rule, if some additional data is still
missing to process a message within a datagram, the message SHOULD be
dropped.
With that many SHOULDs, I'd be worried that implementations using PPSPP can't
count on much. If I receive a message that spans multiple datagrams (even
though it shouldn't), that don't include the necessary hashes (even though it
should), and I don't drop a message with missing data (even though I should),
is that all fine?
In this text:
5.4. INTEGRITY Messages
Concretely, a peer that wants to send a chunk of content creates a
datagram that MUST consist of a list of INTEGRITY messages followed
by a DATA message. If the INTEGRITY messages and DATA message cannot
be put into a single datagram because of a limitation on datagram
size, the INTEGRITY messages MUST be sent first in one or more
datagrams.
Is this assuming that the path between peers will never reorder packets?
There are plenty of comments from other ADs and little more is left to be said. --- It all feels a bit Experimental to me, but I'll leave that to the judgement of the responsible AD. --- Section 3.4 is a bit mixed with respect to the transport. It talks about "if PPSPP is run over an unreliable transport protocol", but the only transport defined is UDP so the "if" is unnecessary and the subsequent clause is pointless. This is confirmed by the text later in the paragraph that confirms that LEDBAT is used and so implicitly confirms that UDP is used. Should be simple enough to tidy up.
My DISCUSS here is based mainly on the readability of the document, which seems bad enough to be an impediment to interoperability. As far as I can tell, this document does not define a protocol, in the sense of a set of actions required to achieve a given objective. Instead, it presents a pile of piece parts with a couple of combinations, and notes that these combinations could be used to achieve, e.g., live streaming. (In the language of patents, it has not been "reduced to practice".) What are the steps an implementation follows to join a swarm? To connect to a new peer and request chunks? The pieces seem to be here, but the big picture is completely absent.
"In general, no error codes or responses are used in the protocol; absence of any response indicates an error." -- This made me do a bit of a double-take. Obviously, the requesting peer should timeout if the responding peer doesn't respond, but are there really no cases where the responding peer knows there's a problem and wants to report it? It seems like the CHOKE message is an indication of this sort.
Thanks for handling my various discuss points. I think you sorted them all, though I have to say I'm not clear whether or not point (6) was sorted or not, that's below.... "(6) 8.4: I don't see the swarm's metadata record in the ascii art diagram and you just say "look at section 7" so two questions: a) where is the "chunk size used" option in section 7? and b) do all the swarm metadata options have to be sent each time with no limit on ordering except as given in section 7 (which had one such order sensitive limit I think)?" However, I'm fine to make this a comment, on the basis that I don't remember whatever it was I meant by that:-) I'm also not so sure the s/ppsp:/file:/ URI scheme swap will really be a fine idea, but it certainly does get past my objection:-) --- OLD comments below here, I did not check these for -12, but am happy to chat about them if you want. - Kathleen has the secdir review point covered. - overall comment: This is too long. - The elephant is in the room, but not the intro:-) Surely some comparison with BT is needed in the intro? The first reference is in 3.7 on p13, which just seems wrong. If this is somehow inspired by BT (can't recall) then maybe say so and add a quick sketch (2-3 sentences) on how this differs from BT. Those would really help the reader IMO. Note that this could be done by reference. - 1.1: I really dislike the term self-certification as its quite misleading. I guess its probably too late to get rid of that but what (I think) is going on here is really naming chunks so that if you know the hash of the entire content you can verify that the chunk is from that. (CHECK!!!) - 1.3, 'content': s/asset/file/ would be better I think and less capitalist;-) The term asset is odd here anyway. Same elsewhere. (But note this is really nitty, no need to change unless you want to.) - 3: I don't get what is meant by this "an external storage mapping from the linear byte space of a single swarm to different files" I can sorta see what's meant, but am not sure. Maybe try clarify? - 5.3, last para: Is the 1st MUST there really implementable in general? I think the MUST might be to include those hashes that the sender thinks the receiver needs. - 6.1 - this defines two methods yet says "If the protocol operates in a benign environment the method MAY be used." Which is meant here? - 6.1.2.1: what if different folks think NCHUNKS_PER_SIG has different values? How do we all agree on a value? (BTW, the last sentence of this section is a cool thing.) - 7.4: "In other cases a peer MAY include a swarm identifier option, as an end-to-end check." That's not clear to me, what other cases? - 7.6: I don't get why you need so many options here. Do you really? SHA1 is probably only needed for legacy stuff (is there any of that?), and SHA256 should be fine for everything else. - 7.8: The width of the figure seems wrong. - 7.10: An example compressed encoding would be useful. - 8.16: "perfectly detected" - huh? what does that mean?
The authors have an updated draft ready which addresses IANA's concerns. The updated draft will be posted after the 7/10 IESG telechat. Here is the text proposed by IANA: OLD: IANA is to create the new registries defined below for the extensibility of the protocol. For all registries, assignments consist of a name and its associated value. Also for all registries, the "Unassigned" ranges designated are governed by the policy 'IETF Review' as described in [RFC5226]. NEW: This document is to create a new top-level registry called "Peer-to-Peer Streaming Peer Protocol (PPSPP)", which will host the six new sub-registries defined below for the extensibility of the protocol. For all registries, assignments consist of a name and its associated value. Also for all registries, the "Unassigned" ranges designated are governed by the policy 'IETF Review' as described in [RFC5226].
There has not been a response to Christer Holmberg's Gen-ART review. Do the authors have a view on the questions he asked? For what it is worth, when I read sections 8.14 and 8.15 they do not give as precise instruction for the implementer about how to handle keepalives and dead peer detection as I’d personally like to see. Perhaps a sentence could be added to explain what a node does (or stops doing) when it declares a peer dead.
2.2 - s/disjunct/disjoint
3.1.1 -
OLD
2. The receiving peer Q checks the HANDSHAKE message from peer P.
If any check by Q fails, Q MUST NOT send a HANDSHAKE (or any
other) message back, as the message from P may have been spoofed
(see Section 13.1). Only if P and Q are in the same swarm, and Q
is interested in communicating with P, Q MUST a datagram to P
that starts with a HANDSHAKE message. This reply HANDSHAKE MUST
contain:
NEW
2. The receiving peer Q checks the HANDSHAKE message from peer P.
If any check by Q fails, or if P and Q are not in the same swarm,
Q MUST NOT send a HANDSHAKE (or any other) message back, as the
message from P may have been spoofed (see Section 13.1).
Otherwise, if Q is interested in communicating with P, Q sends a
datagram to P that starts with a HANDSHAKE message. This reply
HANDSHAKE MUST contain:
END
3.10.1 - "Physically"? I think you can strike that.
4.3.1 - s/MUST send/sends
5.2 - s/MUST receive/needs
5.3 -
OLD
In short, the sender MUST put into the datagram the hashes he
believes are necessary for the receiver to verify the chunk.
NEW
In short, the sender MUST put into the datagram the hashes that
are necessary for the receiver to verify the chunk.
I don't understand what the sender's beliefs have to do with this.
1.1 says, "PPSPP is a generic protocol which can run directly on top of UDP,
TCP, or other protocols." Section 8 says, "PPSPP implementations MUST use UDP
as transport protocol and MUST use LEDBAT for congestion control [RFC6817].".
One of those two statements is lying.
8.5-8.13 - I was really confused for a moment becuase the destination channel
ID did not appear in any of these sections. Either show it, or say somewhere
that it is left out of all of these sections.
I am still reading this draft, but don't see any response to the SecDir review that raised some very important points for discussion: http://www.ietf.org/mail-archive/web/secdir/current/msg04879.html I'll amend this when I get further into my review and would appreciate a response to the SecDir review. Thanks!
Nice work. This is a well written document, and what looks like a solid protocol. General question on the chunking: Is it the case that a given piece of content is chunked in a specific way, with known chunk IDs, such that every peer that's serving that content up (at least in the same swarm) uses the same chunks with the same chunk IDs? One can guess that from the way things work, but shouldn't the document say that? Or does it, and I missed it? -- Section 3.7 -- When peer Q receives multiple REQUESTs from the same peer P, peer Q SHOULD process the REQUESTs in the order received. What happens if it doesn't? Is there an interoperability issue here? A performance issue? Or what? (That is, why is this a 2119 SHOULD?) -- Section 5.3 -- Thus, as a datagram carries zero or more messages, neither messages nor message interdependencies SHOULD span over multiple datagrams. The negatives in this sentence really make the SHOULD a hidden SHOULD NOT, and its meaning is unclear. I think it would be clearer if it were worded that way: NEW Thus, as a datagram carries zero or more messages, both messages and message interdependencies SHOULD NOT span multiple datagrams. END -- Section 12.1.1 -- Nit: "setup" is a noun; "set up" is a verb. In these two sentences, "setup" should be changed to "set up": A content provider wishing to use PPSPP to distribute content should setup at least one PPSPP server. In addition, a content provider should setup a tracking facility for the content by configuring, for example, a PPSP tracker
In general, I found this draft very clear and understandable. I do understand Richard's discuss that the specific message send-responses aren't given concisely, but I think it is understandable. In Sec 4.2, section after Figure 2: Please s/chunk 0..3/chunk C0..C3 and s/chunks 0 and 1/s chunks C0 and C1 This is just because I had to read it 3 times to stop being confused between the bin numbers and the chunk numbers, so I'd ask for consistency. In Sec 5.2, first paragraph: Please change "For chunk C4 its uncles are nodes 13 and 3, marked with * in the figure." to "For chunk C4 its uncles are nodes 13 and 3 and its sibling is 10; all marked with a * in the figure." In Sec 7.8, the bit figure only goes to bit 12 instead of bit 16 - but the range of CAM and the length listed is 8. In Sec 7.9, can you please add a reference to Table 6 where appropriate? Sec 8.1: typo: mebibyte Sec 8.1: The paragraph on PLPMTUD is a bit confusing. Presumably this is between two peers - but the chunk sizes used by the swarm would be specified by the initial seeder. Thus I can see the PLPMTUD variant being useful to decide upon the PPSPP datagram size, but not the chunk size. Could you please clarify either what I'm missing? Sec 8.13: typo in first line: s/PEX_RES/PEX_RESv4
I support Richard's discuss on the viability of this document as a protocol specification and Alissa's point on the use of LEDBAT.
Thanks for addressing my discuss and comment points.
draft-ietf-eman-energy-monitoring-mib
Thanks for adding the new privacy boilerplate. I guess I'd be happier if the privacy issues with power monitoring were more to the fore, but at least recognising the issues is a start and my preference in that regard aren't a good basis on which to block progress.
Thank you for adding in text on privacy considerations as well as strengthening the language on the possibility of attacks to motivate use of SNMPv3 with associated security controls.
I support the issues raised by Alissa and Kathleen.
Thanks for addressing my comments.
former discuss, we processed this. -12 should soon be forthcoming to address the accidental inclusion of eoPowerStorageType StorageType in draft 11 which was merged from a previous draft.
draft-ietf-eman-energy-aware-mib
Please see. [1] [1] https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/#stephen-farrell
Thank you for updating the SNMP boilerplate to add in concerns for IoT security and privacy from my prior discuss.
I do support Kathleen's concerns about updating the security considerations for IoT MIBs.
Thanks for addressing my comments.
draft-ietf-eman-battery-mib
Thanks for addressing my Comments and explaining the error of my Discuss.
- Please see. [1] [1] https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/#stephen-farrell - I support Pete's discuss. And echo his concern that similar comments raised before on the reqs and framework don't seem to have resulted in the wg considering these issues. - I did not have time to fully read this sorry but I've also in the past asked if there are no issues with solar powered devices. I again see no mention of solar power nor of charge controllers (is that the same as a batter controller?) so I again agree with Pete that the coverage here doesn't seem correct - Pete's more concerned with BIG devices whereas I'm more concerned with those that might be deployed in odd and out of the way places:-)
I'm updating my ballot to reflect the discussion we've had so far. My conclusion is that energy generation systems (solar, wind, or nuclear and coal for that matter) are out of scope for EMAN generally, and batteries used in such systems are out of sope for the battery MIB. I'm a bit disappointed by that, but I won't object to the document if that is the intent of the WG. However, if that is true, it really needs to be said in the introduction to this document, and likely should be even more explicit in the applicability statement document. I suggest inserting the following paragraph in section 1, just before the discussion of UPS devices. (Feel free to edit.) Specifically out of scope for this document are batteries that are part of energy generation systems. Such systems, whether they are off-grid power generation systems (e.g., solar, wind, fuel-cell) that maintain their own storage or traditional small- or large-scale generators (anything from microgenerators to utility-scale power plants), have much different monitoring and control interfaces to their battery systems than those of the type of network-attached devices that this document is trying to support. See [draft-ietf-eman-applicability-statement] for more information regarding the applicability of this technology.
Thanks for addressing my points.
Thanks for making the updates to the security considerations that were made across 3 documents and reflected our work on the updated SNMP security boilerplate for IoT security and privacy.
I support Pete's discuss.
Thanks for addressing my comments. I still think the use of normative language in this bit of Section 5 text is a little strange, but I can also understand an argument for having it there: Implementers SHOULD use appropriate privacy protections. Battery monitoring of devices used by individuals SHOULD only occur with proper authorization.
draft-josefsson-pkix-textual
The Abstract says: This document is intended to articulate the de-facto rules that existing implementations operate by, and to give recommendations that will promote interoperability. ...yet the document is on the Standards Track. Actually, I think that Standards Track is fine, but that this wording is too floppy. You could have... This document articulates the de-facto rules by which existing implementations operate, and defines them so that future implementations can interoperate.
Mostly editorial, but a couple of substantive comments on the ABNF: 2 - OLD Whitespace MAY appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such whitespace. NEW Whitespace, carriage returns, and linefeeds can appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such characters. It's not clear that "CR" and "LF" are included in the word "Whitespace". Also notice the change from "MAY" to "can"; that MAY appears to contradict the SHOULD. If you want, you can add a "MUST ignore" for parsers. 3 - A reference to RFC 5234 would be useful, noting that you are importing ALPHA, DIGIT, WSP, CR, LF, and CRLF. There is no "::" in ABNF. A slight simplification: OLD label ::= labelchar *(labelchar / labelchar "-" / SP) labelchar NEW label = labelchar *(labelchar ["-"] / SP) labelchar So, do you really want to require a minimum of 2 labelchars? If not, you could instead have: label = labelchar [*(labelchar ["-"] / SP) labelchar] That would allow for a single labelchar label. Also, do you really want to allow as many spaces as desired between the first labelchar and the last? If you only want to allow one space: label = labelchar *(labelchar ["-" / SP]) labelchar And again put everything after the first labelchar in square brackets if you want to allow for a single labelchar. Editorial: OLD This specification RECOMMENDS that new implementations emit the strict format (Figure 2) specified above. NEW New implementations SHOULD emit the strict format (Figure 2) specified above. 5.1, 6, 7, 10, 11, 12, 13 - Editorial: OLD (DER [strongly] preferred) NEW (DER [strongly] preferred; see Appendix B) 5.1 - Editorial: OLD are NOT RECOMMENDED to NEW SHOULD 5.3 - Editorial: OLD This Internet-Draft RECOMMENDS that the extension ".crt" be used NEW the extension ".crt" SHOULD be used 6 and 8 - Editorial: OLD Parsers are NOT RECOMMENDED to NEW Parsers SHOULD NOT
- intro, para about alg agility - why is this here? I'd say it could be deleted. - intro, the example about cut'n'paste of cert chains is misleading isn't it? What format actually allows that? Isn't the actual practice that the whole chain is b64 encoded and so can't just be catenated? - intro, s/M. Rose/Marshall Rose/ would be better - [X509SG] reference - I thought Peter had a more easily referencable version of this published somewhere. That might help with the RFC editor. I'd suggest asking Peter if there's a better ref to use in addition. (I'd also say that that URL has been stable for quite a long time when you're asked, but I'm sure the RFC editor will nonetheless be unhappy with it for the usual not-bad reasons:-) - section 2, 2nd para: you say it's ok if the labels on the BEGIN and END don't match, but then you say that there (implicitly) MUST be 5 dashes at the end - why is laxity ok for one part of the END line but not another? - section 8: degenerative is wrong unless pkcs#7 has a bone disease or something:-) "specific" would do instead I'd say. - section 14, last para: "namely" is wrong, I think you only need to say "e.g.," as there could be mnay possible canonical forms, not just DER. Or saying "most commonly, DER" would also be ok I think. - The author's way of handling the comments doesn't work for me to track the secdir review [1] responses, but the I don't think there was anything there that can't be handled between author and reviewer. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05268.html
I could not ballot YES more emphatically. I can't tell you the number of times I've looked for a spec for "PEM formatted $FOO". With that in mind: Should this document formally update PEM, and become the new official spec for PEM-encoded objects? Have the relevant communities been involved to make that a reasonable option? Section 3: Is there a way to modify the "base64finl" production to ensure it maxes out at 64 characters? I'm not enough of an ABNF wizard to know.
Pete has this in hand -- particularly the discussion of the ABNF for "label".
draft-ietf-mptcp-attacks
Generalising from the discuss text posted eariler: In what sense is the list of 5 attacks here complete? If this list is not complete, then on what basis were these attacks selected? I think you need to say. There is a real danger that we only document (and mitigate) attacks that we find interesting or have a plan for mitigation, so I'd like to know how this list was arrived at.
- section 2 (and elsewhere): You have a "Threat: Medium" here, but you don't say what you mean by "Threat." Given that you cannot estimate any probabilities I would guess you mean something like "impact" possibly modulated by the difficulty of mounting the attack. I'd say it'd be good to say what you do mean by threat, or perhaps even change to say in this case "Impact, Difficulty : Medium, Medium" or some such. And the same elsewhere. While there are a lot of different ways you can do this that are equally good, but "threat" is probably the wrong word, and whatever word(s) you do use probably need some definition. (Which could be via RFC4949 if you like, though that has some ambiguities.) - p5, s/the Linux implementation/the current Linux implementation/ would be more accurate (and don't they prefer GNU/Linux?) - section 5: I can't see how the threat here is low for any reasonable definition of threat. - section 6 assumes that "acceptable" == "low (threat)" That seems a bit self-serving though - is it fair really? - 5.1: There may be cases where there is the potential to (post-facto) detect, but not prevent, a MitM. Not sure that it'd work for MPTCP though, given NATs mean the endpoints can't be sure of the identifiers used, but if at least one subflow is not NATed and if there were a DH exchange, then it could be possible to post-facto detect a MitM and it could be that some use-cases might be such that the endpoints would prefer to fail the connection rather than allow for a connection with a possibly undetectable MitM. Or, if there are cases where it'd be hard for the potential MitM attacker to know if NAT had happened or not, then that might movitate the attacker to hold off in case they are later detected. There's lots of speculation there though, so I'm not recommending any particular action, but I do think it'd be worth considering and maybe documenting later on. Probably too speculative to be worth a mention here though. (And it does depend on a DH exchange.) - 7.1: Surely TCPINC deserves a mention here? - The secdir review [1] also made a couple of points that are worth a look, but hasn't gotten any response that I can see. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05162.html
Me filing a security-related DISCUSS, I'm surprised myself :-) Briefly chatting about the issue with Stephen Farrell, discovered by Stefan Winter part of his OPS-DIR review, he advised me to file a DISCUSS about this issue. I expect the Security ADs to follow up on this one. From an OPS-DIR perspective, the document is Ready with very minor nits. From a security perspective, IMHO not so. The following are comments from my individual perspective, which I hope can be considered even though being so late. The document readily admits that an attacker who can eavesdrop parts of the connection can hijack and MitM the connection to his liking. The document states in section 5 that: "This vulnerability was readily identified at the moment of the design of the MPTCP security solution and the threat was considered acceptable." I believe the design of MPTCP predates the IETF's "perpass" considerations and did not take into account that pervasive passive attacks are possible and are being conducted at large scale on the internet on a day-to-day basis. The -attacks document now provides an easy-to-follow recipe to mount the attack, with the only prerequisite being that TCP headers can be inspected by an attacker. MPTCP itself and its security implications need to be revisited (which is happening in the -bis document; I strongly hope that this is one of the parts which do get fixed). The suggested mitigations 1 and 2 in section 3.1 of the -attacks draft do not help in this scenario, because the additional information can be trivially eavesdropped. Mitigation 3 seems to prevent it, but is not the recommended one. In my understanding, none of the three are part of the actual protocol anyway. Does the mptcp-bis document go towards that mitigation 3, or did it find another way to prevent the described elevation from pervasive passive to off-path active MitM? From my understanding, the recommendation in section 7 does not point towards that (best) mitigation nr. 3, which I find unacceptable as a recommendation for a standards-track-to-be. The draft in its current state does not discuss perpass-style scenarios in the ADD_ADDR attack and their consequences in an adequate manner, and inappropriately classifies ADD_ADDR as a "medium" threat. From a security perspective, I would not find the document satisfactory and would like to see it revised.
The following NITs are in the document: Section 3 --------- SYN-flod -> SYN-flood on-time attacker -> on-path attacker (?) Section 7 --------- The caption of section 7 has a typo: Reccomendation -> Recommendation
I have two very simple points I'd like to discuss, please: 1. RFC 6824 has to be a normative reference, surely... doesn't it? Is it really possible to understand this document without it? 2. As I understand this document, it's basically updating RFC 6181 with additional threat information that has come out of the development of 6824. The complete MPTCP threat analysis is now 6181 plus this document, yes? So shouldn't this document be marked as "updates 6181"?
The third sentence of the Introduction has the phrase "during the design of" twice, giving it a muddied meaning. Can you please rephrase that sentence?
I'm a Yes. I'm supporting Barry's small Discuss points, and assuming Barry will resolve them with the authors.
I am confused about the "Threat: Medium" and "Threat: Low" labels, and I don't think they really stand on their own without further explanation. It is unclear whether what they are intended to measure is the cost, likelihood, likely impact, or ease of mitigation of each threat. Perhaps all of those factors are relevant to discuss, but as of now they aren't discussed in a systematic way across the threats and the single label per threat provides very little information about how it was derived or what it means. I would suggest either removing the labels or expanding the explanation of what they mean.
draft-ietf-jose-cookbook
- 3.3, 1st para says private where it should say public - thanks for addressing the (heroic:-) secdir review [1], I think in the end you got everything rigth? [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05249.html
Note: I have personally validated the examples in Sections 3.1, 3.3, 4.1, 4.2, and 4.3. I used them in tests for a JWK/JWS library. (The only difference between the text and the test case is that I had to add a "jwk" header field, because my code doesn't support lookup based on "kid".) https://github.com/bifurcation/gose/blob/master/jose_test.go#L36 Now we just need RosettaCode entries for JOSE operations :) http://rosettacode.org/wiki/HTTP Section 1.1.: """ Unless otherwise noted, the JWE plaintext or JWS payload content does include " " (U+0020 SPACE) characters. Line breaks (U+000A LINE FEED) replace some " " (U+0020 SPACE) characters to improve readability but are not present in the JWE plaintext or JWS payload. """ I think Barry commented on this in his pre-review, but it would be good to clarify this. Perhaps you could describe the examples as a sequence of quoted strings, which the user should concatenate? For example, in Section 4: """ "It\xe2\x80\x99s a dangerous business, Frodo, going out your " "door. You step onto the road, and if you don't keep your feet, " "there\xe2\x80\x99s no knowing where you might be swept off " "to." """ I agree with Alissa that "progenitor" is inapt. "Private key corresponding to" is the typical phrasing.
The authors engaged in the discussion with the OPS-DIR reviewer Jouni on the points below. Thanks Few minor nits & comments: o IDnits spits out warnings. I recon all of them are of kind that will be corrected by t he RFC Editor -> no worries. o The document uses example domains "hobbiton.example" and alike. According to RFC2606 & 6761 the example domains are "example.com" etc. These should be corrected UNLESS they cause too much trouble regenerating outputs into examples... o line 325 "coordiates" should probably be "coordinates". o I would take acronyms (e.g. "(JWS)") away from the abstract.
I've already made these comments by email, and discussed them with Matt. I'm quite satisfied that they're in hand, and no further response is needed. My experience is that any time there is a significant number of examples, some of them will be wrong. My experience is also that readers will find those errors and will delight in filing errata reports. The shepherd writeup says that the compact encodings, at least, have been checked for correctness, and I'm trusting that this is adequate. But please have pity on the Sec ADs and their successors, who will have to deal with the inevitable errata, and quadruple check things. And make sure that errors are not introduced during RFC Editor processing. Do a more-careful-than-usual check during AUTH48. In particular, it is very importantant that the RFC Editor perform no editing at all on the cleartext payloads. For example: It\xe2\x80\x99s a dangerous business, Frodo, going out your door. You step onto the road, and if you don't keep your feet, there\xe2\x80\x99s no knowing where you might be swept off to. If the RFC Editor's editing should double-space the sentences, your examples based on the published cleartext would then be wrong. Please make sure the the RFC Editor understands that they must not alter that text in any way... and then please check that during AUTH48. -- Appendix A -- Not that it matters terribly, but during AUTH48, you might coordinate with the RFC Editor to make sure that single spacing (not double, as now) is used after the periods in "J. R. R. Tolkien". Kathleen might put this into an RFC Editor note.
I would suggest using a simpler word than "progenitor" in 3.2 and 3.4 (unless it's a term of art, but it doesn't seem like it is).
ok with the outcome of the opsdir review.
draft-ietf-ianaplan-icg-response
I am absolutely delighted by this document. I think it's a good and useful read even outside of its intended context, and serves its intended purpose well. I would like to personally commend the working group for producing such a good document so quickly. I do have one comment: This mechanism is global in nature. The current agreement does not specify a jurisdiction. I am puzzled by the use of the term "global" here. I would have said "international." That said, I actually found Pete's suggested text to be a huge improvement. I think the current text is, while not exactly vague, at least easy to misunderstand, so I would encourage the WG to consider adopting Pete's version. I think Pete's longer text contextualizes the term "global" in a way that requires no further adjustment. I am not in love with "we largely are there already" because it's a difficult idiom. I'd suggest the following instead: OLD: And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made. NEW: And we believe that this is for the most part the current situation, although the system can be strengthened further, and continuous improvements are being made. I am not in love with this turn of phrase: We fully understand the need to work together. This seems to imply that we had to be convinced. I would rather that we said something like this: We believe that we must continue to work together. OLD: many people participate in email discussions that have never attended an IETF NEW: many people participate in email discussions who have never attended an IETF I am happy with this document whether the changes I've suggested above are adopted or not. Thanks for the good work!
Typo: bottom of p. 11: s/ organizaitons / organizations
My comments (archived below for completeness) have all been addressed by the editors who plan a new revision. === Thank you for working on this document and capturing the consensus of the comments you received. I have a few editorial points and some minor questions I hope you will have time to consider. --- The Shepherd write-up says... The I-D should not be published as an RFC immediately after approval. Instead, the IESG should hold it and transmit its approved status through its appointees to the ICG. If discussion with the ICG results in proposals to change the proposal, such changes will need to be discussed in the WG. The advantage of this approach is that a bis to an RFC is not required. This would save RFC Editor time, and possibly avoid confusion later. But this seems a minimal benefit. On the hand, I don't see how discussions with the ICG would result in changes to IETF consensus material. Maybe the point is that the ICG might have questions about the clarity or about missing material. The process here may be slightly out of alignment. Getting external review is normally handled prior to, or during IETF last call. Very occasionally it is also handled immediately after IESG last call. Having external review after approval for publication seems to be running things a bit late. Perhaps what you wanted to achieve was IESG review rather than IESG approval? --- idnits throws some issues and warnings. These are not mentioned in the Shepherd Writeup, but I don't think any work is actually needed. -- This document includes language that was natural in the I-D as it was under development, but would be inappropriate in a published RFC. Title Strike "Draft" Abstract Strike the final sentence. I do not believe that Section 5 is appropriate in an IETF Stream document. --- Section 1 para 1 talks says They solicited proposals regarding post- transition arrangements from the three functional areas In a paragraph mentioning many groups of people, it would be helpful to be explicit instead of saying "They...". I think you mean "The ICG...". It is unclear at this stage of the document what a "functional area" is and it is hard to understand whether the word "from" is intended (the three functional areas should provide proposals about the whole set of transition arrangements) or is intended to read "for" (proposals should be made relating to the transaction arrangements for each of the functional areas). Although this does not change the response itself, clarity would be helpful. --- Section 1 The paragraph... As if to demonstrate the last point, the following text was included in a footnote in the original RFP: ...is either bdly placed or badly worded. It appear that the original RFP was attempting to demonstrate that there are small changes to the content of the questions asked in order to match the RFC format. I doubt that this is what you are trying to say! --- Section 1 Please indent the final paragraph to make it more clear that it is quoted from another document. --- I wondered whether RFC 7120 needed to be referenced. I also wondered whether the Errata Report system should be indicated. Both of these have mechanisms that cause changes in registries without necessitating RFCs. --- Page 11 s/organizaitons/organizations/ --- Page 11 IETF community is quite satisfied The conflict between common usage and correct (British - cf. Jane Austen) meaning of "quite" makes this ambiguous. I suggest you use an alternative such as "reaosnably", "very", or "completely". NB. You use the correct definitive usage in bullet 3 on page 13. --- Page 12 Discussions during the IETF 89 meeting in London led to the following guiding principles for IAB efforts that impact IANA protocol parameter registries. These principles must be taken together; their order is not significant. This text appears to be saying that the consensus embodied in this document is that these principles are a result of the London discussions. It does not imply that there is consensus on these principles themselves. If the latter was intended, then some rewording may be beneficial, such as: The IAB carries out a number of activities that impact IANA protocol parameter registries. The following principles guide how the IAB carries out these activities. These principles must be taken together; their order is not significant. However, the later use of the first person plural is then very ambiguous. When you write... We think the structures that sustain the protocol parameters registries function need to be... ...who is "we". Is it the IAB or is it the community? So perhaps you are just using this document to record the IAB's views on things without any IETF consensus. That would be fine, but perhaps it would be better to put that material in an IAB RFC or an IAB Statement, and reference it from this document. Lastly, the text doesn't really read like guiding principles. It is more some general observations and afirmations. So you might want to change the term. Indeed, you conclude the response with These principles will guide the IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures. ...which is counter to the initial statement that these are guiding principles for IAB efforts. --- Page 15 The policies and procedures are outlined in the documents we named above. Any reason not to repeat the citation for clarity? --- Question V "Support and enhance the multistakeholder model" I don't feel that the response addresses multistakeholerism in the the transition. it talks about how great the IETF is (which is true) but not about the transition proposal. To some extent you could argue that the proposal is that the IETF should retain substantial control, and so talking about the IETF's model is relevant, but this does not jump out of the text. Furthermore, there are elements of the contract and oversight that surely need to be stated. --- As mentioned by others, the response to question VI needs further work. You should probably have drafted this and included it with a caveat so that the community could see what you proposed to deliver. In any case you need: >>> o The steps that were taken to develop the proposal and to >>> determine consensus. - WG last call - IETF last call - IESG evaluation >>> Links to announcements, agendas, mailing lists, consultations and >>> meeting proceedings. - Publication request - IETF last call announcement - IESG ballots - IESG approval announcement >>> An assessment of the level of consensus behind your community's >>> proposal, including a description of areas of contention or >>> disagreement. - Text! (Before the provision of this text, it is hard for the IESG to ballot) --- Section 4 might benefit from observing that part of one of the questions was: >>> "Maintain the security, stability, and resiliency of the >>> Internet DNS;" So security is a specific as well as a general concern. --- As previously mentioned, section 5 is odd. --- Some of your reference are normative. That is, in some cases you do not answer questions with direct text, but say "This is explained in [Foo]." That makes [Foo] a normative reference. In this category I see (at least) [http://www.ntia.doc.gov/page/iana-functions-purchase-order] [RFC6761] [RFC6220] [RFC5226] [RFC2026] [RFC2418] [NTIA-Contract]
I'm absolutely fine with this going forward as-is caveat one question below.
Otherwise, my other four comments are completely stylistic/editorial that I
found during my final review: If the WG finds them useful, great, but if you
don't change them, I will still be fine with the document going forward as-is.
First my question: In section 2, you say:
>>> An assessment of the level of consensus behind your community's
>>> proposal, including a description of areas of contention or
>>> disagreement.
>>>
IETF Response: To be completed as the process progresses.
Is the IESG being asked to fill that in at the end of the process? I think
that's a reasonable choice, but I wanted to make sure that someone had the
token. You should probably add a note here to indicate who is expected to draft
that text.
Now, as to the editorial comments:
In section 1, "the three functional areas" are not identified in the first
paragraph of the intro. Perhaps they should be?
In section 2, I thought that:
The IETF is a global organization that produces voluntary standards,
whose goal is to make the Internet work better [RFC3595].
sounded a bit cheesy. I think it would sound more professional to use the full
mission statement from 3935 instead of the goal statement:
The IETF is a global organization that produces voluntary standards,
whose mission is to produce high quality, relevant technical and
engineering documents that influence the way people design, use, and
manage the Internet in such a way as to make the Internet work
better [RFC3595].
Maybe too much of a mouthful, but I think it sounds better. Entirely up to the
WG.
Also in section 2:
>>> VI. Community Process
>>>
>>> This section should describe the process your community used for
>>> developing this proposal, including:
>>>
>>> o The steps that were taken to develop the proposal and to
>>> determine consensus.
>>>
IETF Response:
The IESG established the IANAPLAN working group to develop this
response. Anyone was welcome to join the discussion and participate
in the development of this response. An open mailing list
(ianaplan@ietf.org) was associated with the working group. In
addition, IETF's IANA practices have been discussed in the broader
community, and all input is welcome.
The simple editorial point is that everything else is in the past tense except
for the the last sentence, which switches from present perfect to present.
Present perfect seems right for everything except the first sentence. The other
point about this is that it doesn't quite answer the question about the steps
taken to determine consensus. Here's a suggested replacement; the stuff in
curly braces is if the group thinks it's worth being more explicit:
IETF Response:
The IESG established the IANAPLAN working group to develop this
response. Anyone has been welcome to join the discussion and
participate in the development of this response. An open mailing
list (ianaplan@ietf.org) has been associated with the working group.
In addition, IETF's IANA practices have been discussed in the broader
community, and all input has been welcome. Normal IETF procedures
[RFC2026] [RFC2418] were used to determine rough consensus{: The
chairs of the working group reviewed open issues and, after an
internal working group last call, determined that all had been
satisfactorily addressed, and subsequently the IESG did a formal
IETF-wide Last Call followed by a formal review and determined that
the document had rough consensus}.
Finally, one last editorial bit: When providing the links to announcements, I
suggest using the mailarchive.ietf.org ones instead of the mailman ones (which
appear in the "Archived-at:" of each message). The mailarchive.ietf.org links I
believe are intended to be the place to find mail over the long term.
I think Adrian's points are valid and well worth bottoming out on but I'll end up a yes on this unless something very crazy happens. And balloting ahead of that having happened is maybe a good demonstration that not every single word in this draft is gigantically important to the extent that getting one word wrong will cause the Internet to come crumbling down. The basic thrust, and the detail, of this are good. I look forward to seeing Adrian's issues with the end stage processing of this being sorted out smoothly.
I agree very strongly with the overall approach of the document, and having watch the process, I agree that it represents the strong consensus of the IETF. A few editorial comments below. Abstract: "The IETF community is invited to comment and propose changes to this document." Presumably this should be removed before publication? Section 1: "Note that there are small changes to the content of the questions asked in order to match the RFC format." To be defensive, you might note that these changes only entail shifting white space around (assuming that's true). E.g., "Note that the formatting of the questions has been changed to match the RFC format." Section 1: "As if to demonstrate the last point, ..." Have you lost an antecedent here? I'm lost as to what point is supposedly demonstrated here. Section 1: "In this RFP, ..." It would be good to make this a blockquote to be extra clear that it is not from this document. Section 2, Question II.B: "accountab le" Section 2: "IETF Response: To be completed as the process progresses." Presumably this should be updated before publication? It seems pretty silly to have IANA Considerations and Security Considerations in this document. Surely we can make an exception to the requirements and strip these out?
Thank you for your work on this draft and discussing the important points Adrian raised.
Thanks for taking this task on.
I have a bunch of minor suggestions. The editors are welcome to tell me the
text has already been heavily tweaked, so I should shut up, and I'm already a
Yes ("do the right thing").
After looking at this draft, I'm even less impressed with the way we cite BCPs
than I was yesterday, but that's an IESG problem, and probably doesn't affect
balloting for this draft (no editor action required).
In this text:
Abstract
This document contains the IETF response to a request for proposals
from the IANA Stewardship Transition Coordination Group regarding the
protocol parameters registries. It is meant to be included in an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
aggregate proposal that also includes contributions covering domain
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
names and numbering resources that will be submitted from their
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
respective operational communities. The IETF community is invited to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
comment and propose changes to this document.
This sentence didn't parse easily for me, and I think the problem was just
being too passive and indirect. Perhaps something like this:
Abstract
This document contains the IETF response to a request for proposals
from the IANA Stewardship Transition Coordination Group regarding the
protocol parameters registries. The IETF response will be included in an
aggregate response, along with contributions covering domain names and
numbering resources from the operational communities responsible for those
resources. The IETF community is invited to comment and propose changes to
this document.
In this text:
1. IETF Introduction
Note that there are small changes to the content of the questions
asked in order to match the RFC format.
As if to demonstrate the last point, the following text was included
in a footnote in the original RFP:
I don't understand how the following text demonstrates "the last point" about
small changes to the content of the questions. Were I to guess, my guess would
be "this was a footnote, but RFCs don't have footnotes, so we dragged the text
into the body of the document". Did I get it?
In this text:
2. The Formal RFP Response
>>>
>>> 0. Proposal Type
>>>
>>> Identify which category of the IANA functions this
>>> submission proposes to address:
>>>
IETF Response:
[XXX] Protocol Parameters
This response states the existing practice of the IETF, and also
represents the views of the Internet Architecture Board and the IETF.
Is ^this paragraph part of the IETF Response, or an observation? I'm probably
confused by how the "IETF Response:" line is indented. The next "IETF
Response:" line isn't indented as much, and if this line was indented the same
way, I'd definitely read the paragraph as part of the IETF Response.
FOR THE IESG, no author response required: You have to love this description of
BCP9 ...
The Internet Standards Process is documented in [RFC2026]. That
document explains not only how standards are developed, but also how
disputes about decisions are resolved. RFC 2026 has been amended a
number of times, and those amendments are indicated in [RFC-INDEX].
^^^^^^^^^
Is this the best we can ask authors to do in a document that is going to people
who don't read RFCs for a living? I'm afraid the answer from the IESG may be
"yes" ...
In this text:
It is important to note that the IETF includes anyone who wishes to
participate. Staff and participants from ICANN or the Regional
Internet Registries (RIRs) regularly participate in IETF activities.
I was somewhat confused about whether this is about who the IETF allows to
participate, or about the definition of the "the IETF". Given that you're
trying to describe who's included in non-member organization, perhaps this
could be something like:
It is important to note that the IETF does not have formal membership.
The term "the IETF" includes anyone who wishes to participate in the IETF,
and IETF participants may also be members of other communities. Staff and
participants from ICANN or the Regional Internet Registries (RIRs)
regularly participate in IETF activities.
IN this text:
o The routing architecture has evolved over time, and is expected to
continue to do so. Such evolution may have an impact on
appropriate IP address allocation strategies. As and when that
^^^^^^^^^^^
happens, we will consult with the RIR community, as we have done
in the past.
"As and when" reads roughly to me. Perhaps "As", or perhaps "If and when"?
FOR THE IESG: In this text:
The IAB members are selected and may be recalled through a Nominating
Committee (NOMCOM) process, which is described in [RFC3777].
The use of one RFC as shorthand for a multi-RFC BCP in this case is
problematic, and this text doesn't even give the hand-waving "by the way, that
RFC has been updated, and you can probably find the updates in the RFC-INDEX"
that previous instances included.
In this text:
The IAB provides oversight of the protocol parameters registries of
the IETF, and is responsible for selecting appropriate operator(s)
and related per-registry arrangements. Especially when relationships
among protocols call for it, many registries are operated by, or in
conjunction with, other bodies. Unless the IAB or IETF has concluded
that special treatment is needed, the operator for registries is
currently ICANN.
I don't think the last sentence is right. Is it correct to say "ICANN is
currently the operator for all registries, except for specific registries where
the IAB or IETF has concluded that special treatment is needed"? The current
text reads like ICANN as the operator is all or nothing.
In this text:
We think the structures that sustain the protocol parameters
registries function need to be strong enough that they can be offered
independently by the Internet technical community, without the need
for backing from external parties. And we believe we largely are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
there already, although the system can be strengthened further, and
^^^^^^^^^^^^^
continuous improvements are being made.
The indicated phrase seems very breezy. Perhaps "And we believe those
structures are strong enough now"?
In this text:
>>> V. NTIA Requirements
>>>
>>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements:
>>>
>>> "Support and enhance the multistakeholder model;"
>>>
IETF Response:
Everyone is welcome to participate in IETF activities. The policies
and procedures are outlined in the documents we named above. In-
person attendance is not required for participation, and many people
participate in email discussions that have never attended an IETF
meeting. An email account is the only requirement to participate.
The IETF makes use of both formal and informal lines of communication
to collaborate with other organizations within the multistakeholder
ecosystem.
Is it worth explicitly pointing out that there is no cost of membership?
In this text:
This proposal maintains the existing open framework that allows
anyone to participate in the development of IETF standards, including
the IANA protocol parameters registries policies. Further, an
implementer anywhere in the world has full access to the protocol
specification published in the RFC series and the protocol parameters
registries published at iana.org. Those who require assignments in
the IANA protocol registries will continue to be able to do so, as
^^^^^
specified by the existing policies for those registries.
I don't think that parses. Is this "will continue to be able to request these
assignments"?
In this text:
IETF Response:
The IESG established the IANAPLAN working group to develop this
response. Anyone was welcome to join the discussion and participate
^^^^^^
in the development of this response. An open mailing list
(ianaplan@ietf.org) was associated with the working group. In
addition, IETF's IANA practices have been discussed in the broader
community, and all input is welcome.
I wonder if this text reflects how open the IETF is. It would be correct to say
"Anyone on earth with access to e-mail was able to join ...". That might not be
the right thing to say, but is the current text strong enough?
In this text:
Announcement of a public session on the transition: http://
www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
I'm not sure "public" is the right adjective. Perhaps something like
"Announcement of a face-to-face session with provision for interactive remote
participation? I'm asking because the URL just says there's a session at IETF
90, and that would make a random reader of this document think travel,
accommodations and meeting fees would be required.
I think discussion about the IAB Note is headed the right direction, but that
matters.
What Stephen said...
I support this document enthusiastically. I've provided editorial suggestions below. = Section 1 = "In March of 2014 the U.S. National Telecommunications & Information Administration (NTIA) announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA) functions." You might include a citation: http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions = Section 2 = "There are, however, points of interaction between other organizations, and a few cases where we may further define the scope of a registry for technical purposes." s/we/the IETF/ -- s/ICANN or the Regional Internet Registries (RIRs)/ICANN and the Regional Internet Registries (RIRs)/ -- "Please also see the references at the bottom of this document." This seems too vague. There are many references at the bottom of the document, not all of which are relevant to answering the RFP question about policy development and dispute resolution. It seems like this sentence could be deleted. -- s/with the same affiliation/with the same employment affiliation/ -- "Especially when relationships among protocols call for it, many registries are operated by, or in conjunction with, other bodies." I think this would be clearer if it said "Especially when relationships among protocols call for it, many registries are operated by with input and coordination from other bodies." The "operated" verb is otherwise confusing when read together with the sentence that follows. -- s/all input is welcome./all input was welcome./ (or Pete's suggestion works for me too) -- In addition to Adrian's suggestion, I think the response to Section VI of the RFP needs these direct links: IANAPLAN WG: https://datatracker.ietf.org/wg/ianaplan/charter/ Agenda from IETF 91: https://tools.ietf.org/wg/ianaplan/agenda Minutes from IETF 91: https://tools.ietf.org/wg/ianaplan/minutes Agenda from the interim meeting: <fill in> Minutes from the interim meeting: <fill in>