IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-12-15. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (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:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
Telechat:
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
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
1035 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Working Group News
Amy: we're on vacation from Christmas until New Year's; we had to change Calendar subscription for telechat, it's in your informal wiki page
Alvaro: is there a way without password?
Robert: I don't understand why we'd want to restrict access
Amy: AFAIK it' just for subscription, I'm not the technical person; I can't answer
Joel: I think we could turn off passwords
Amy: I'll take that to the technical folks, no guarantee it will change before new year
1116 EDT Adjourned
(at 2016-12-15 06:00:03 PST)
draft-ietf-manet-dlep
Thank you for a well-written clear document. Every time I had a question, I found the answer in the next section. typo: a) bottom of 11.11.1 " Modems that do not track IPv6 subnets MUST silently ignore IPv4 Attached Subnet Data Items." The IPv4 should be IPv6.
I agree with Alexey's discuss point about the security considerations. -5.1: Is discovery support optional? Can you offer any guidance on a reasonable maximum interval for peer discovery signals? - 5.2: It's probably worth mentioning that the messages from here onward go over the TCP connection established as a result of discovery. Can you offer any guidance on how long a modem should wait for the Session Initiation Message before abandoning a connection? -7, paragraph 2: "they will need to be standardized either as an update to this document, or as an additional stand-alone specification." I'm not sure what the distinction is between an update vs a stand-alone specification in this context. But in any case, it's unusual to require that a spec update an RFC to exercise defined extension points. - 8, first paragraph: "At large scale, implementations SHOULD consider employing techniques to prevent flooding its peer with a large number of Messages in a short time." The SHOULD consider is an odd use of a 2119 SHOULD. If the intent is to tell implentors to think about this, then the SHOULD is probably not appropriate. Or does this mean "implementations SHOULD employ techniques" (which would be perfectly reasonable)? -10.3: This seems to forbid the configuration of non-standard ports. Is that the intent? - 10.5, 2nd to last paragraph: Can you offer any sort of guidance at all for Session Initiation timeout values? -11.5: Do heartbeat messages occur in parallel to other active traffic, or only when things are quiet? Or in other words, do messages other than heartbeats reset the heartbeat interval timer? Can you offer any guidance on reasonable heartbeat interval values, or guidance on how to choose a value? It seems like there could be a lot of heartbeat messages if people choose low values. -12 Is eavesdropping a concern? Could inserted messages be used to direct user traffic over a compromised link? What is the reasoning to not at least require implementation of TLS? Do you imagine situations where it might make sense not to use TLS, other than the mentioned? ("deployments where the DLEP router and modem are the only devices on a physical Layer 2"). Would a "MUST use TLS unless..." construction make sense here? Editorial Comments: - General: Neither the abstract or the first few paragraphs of the introduction mention that this draft creates a protocol. That sort of buries the lede. Please consider mentioning that both in the abstract and near the top of section 1. - 10.5, 2nd to last paragraph: "DLEP Heartbeats are not fully established " I'm not sure what it means to fully establish heartbeats. Would it be reasonable to say "... not started"?
Am I missing something or does the doc not specify which policy/policies should be used for registration of new values in these new registries? (Also previously mentioned by the tsv-art reviewer - thx!)
Technical comments: 1) You say "If a Signal is received with a TTL value that is NOT equal to 255, the receiving implementation MUST ignore the Signal." and "If a packet in the TCP stream is received with a TTL value other than 255, the receiving implementation MUST immediately transition to the Session Reset state." However, there is no requirement that the initial TTL must be 225. I guess you can just add a sentence to require this from the sender. 2) You say: "If an unrecognized, or unexpected Signal is received, or a received Signal contains unrecognized, invalid, or disallowed duplicate Data Items, the receiving implementation MUST ignore the Signal." Would it make sense to also send an error signal in this case or was this omitted as it could be used as a DoS reflector? If so, maybe add a sentence. 3) in section 10.5: "DLEP Heartbeats are not fully established until receipt of the Session Initialization Response Message (Section 10.6), and therefore implementations MUST use their own timeout and retry heuristics for this Message." I'm not sure if re-trying makes sense given that TCP should deliver the data reliably here. I guess time-out to terminate the TCP and a local error log would be more appropriate. 4) section 11.16: "The Latency value is reported as transmission delay. The calculation of latency is implementation dependent. For example, the latency may be a running average calculated from the internal queuing." Not sure if this is very useful. I would either recommend to define to report the average (or max?) latency (where the calculation is still of course implementation specific) or have three different items for min, max, and current average. Editorial comment: The 2119 boilerplate has a weird position as part of a subsection. I assume that this is intended to say that the normative text starts here but it could also be interpreted to be just part of the subsection. Also having 'Requirements' (3.1) as subsection of 'Extension' (3) seems to be an error. I would suggest to have the 2119 boilerplate as well as the Requirements section both as own main level sections. And sec 3 and sec 7 are both called 'Extensions'...? Further: I didn't see a reply to the tsv-art review by Micheal Scharf. Have those comments be addressed? Here is his review on -25: This draft is basically ready for publication, but has nits that should be fixed before publication. TSV-ART review comments: * I think the DLEP protocol makes an implicit assumption that the 1-hop link between the router and the modem is unlikely to become a bottleneck, e.g., because its bandwidth is larger than the maximum possible bandwidth of the modem. I assume that in typical deployments this condition can be fulfilled, and the hop count limitation provides some safety measures. Yet, the link between the router and modem could possibly run over a tunnel, with unknown performance characteristics (e.g., another wireless backhaul link). It is unclear what a router would indeed learn from the information provided by DLEP in such a case. This scenario is not the target environment for the protocol, but it would make sense to more explicitly spell out that assumption, e.g., in Section 1. Other comments: * Page 9: "If the router and modem support both IPv4 and IPv6, the IPv6 transport MUST be used for the DLEP session." seems inconsistent with page 21: "For routers supporting both IPv4 and IPv6 DLEP operation, it is RECOMMENDED that IPv6 be selected as the transport." * I am not an IANA expert but at first sight the IANA section does not comprehensively describe the policy for modifying the IANA registries (Section 4 in RFC 5226). Is it "Standards Action"? This in particular matters for the extensions in Section 13.6.
* Section 11.7 The MAC address encoding on the wire seems to be wrong. Instead of using 6 bytes for MAC-48 the document seems to using 8 bytes. Similarly for EUI-64 the document seems to be using 12 bytes instead of 8. Please fix this (Also Note that the length values specified under the format of the data item seem to be correct i.e. 6 & 8 - it is the data item format that is wrong)
* Sections 11.2, 11.3, 11.9 and 11.10 The IPv4 and IPv6 addresses do not seem to be aligned on word boundaries. Didn't you face any inefficiencies/difficulties due to this in your implementations (I saw there were four independent ones)? * Section 11.11.1 Agree with Alia's point that there seems to be a typo in "IPv4 Attached Subnet"
Matt's Gen-ART comments need to be addressed.
Thanks, Alexey for asking the question on validating credentials in your discuss. It would be good to see more clarity on how that will be done and I see the response stating it is an outstanding problem in Manet - I'd like to know the plan to solve this.
This is generally a well written document and I enjoyed reading it. I have a small set of questions which I would like to discuss before recommending approval of this document: 1) In 10.4. Peer Offer Signal A Peer Offer Signal MUST be sent by a DLEP modem in response to a properly formatted and addressed Peer Discovery Signal (Section 10.3). A Peer Offer Signal MUST be encoded within a UDP packet. The IP destination MUST be set to the IP address and port number received in the corresponding Peer Discovery Signal. The source IP address MUST be set to the modem's IP address associated with the DLEP interface. The source port number MUST be set to the DLEP well-known port number. The port number can be omitted to signal that the well-known port number is to be used (as per 11.2 and 11.3). It looks like requiring that the source port is always a well-known port is an error here. 2) In 10.17: If metrics are supplied with the Message (e.g., Resources), these metrics are MUST be applied to all destinations identified in the Message. Nit: extra "are" before "MUST". Question: how can multiple destinations be specified? Note that this may overwrite metrics provided in a previously received Session or Destination Up Messages. 3) 12. Security Considerations At the transport layer, implementations of DLEP SHOULD implement, and use, TLS [RFC5246] to protect the TCP session. Deployments that are protected by strong physical security (e.g., deployments where the DLEP router and modem are the only devices on a physical Layer 2 segment) may consider use of DLEP without TLS. When TLS is in use, each peer SHOULD check the validity of credentials presented by the other peer during TLS session extablishment. Refer to [RFC7525] for additional details. How can credentials presented by the other peer can be validated? RFC 7525 is referencing RFC 6125, which talks about hostname validation, which is something which might not apply to DLEP deployments?
In Section 6, last para: DLEP transactions do not time out and are not cancellable. What exactly does this mean? Does this mean that a router (or modem) can terminate a session, then reconnect later on and continue the transaction? Or did you mean something else? An implementation can detect if its peer has failed in some way by use of the session heartbeat mechanism during the In-Session state, see Section 5.3. In 10.2, 2nd para: A DLEP participant receiving any Message apart from Session Termination Message (Section 10.9) containing a Status Data Item with a status code value with failure mode 'Terminate' MUST immediately issue a Session Termination Message containing an identical Status Data Item, and then transition to the Session Termination state. I had to reread this multiple times, but I still want to double check whether I understood this correctly: are you saying that the Session Termination Message echoes back the Status Data Item that caused the session to terminate? If yes, you might want to reword this in order to make this clear. If no, you should definitely reword this ;-). 10.9. Session Termination Message A Session Termination Message MUST be sent by a DLEP participant when the DLEP session needs to be terminated. This probably means "MUST attempted to be sent", because the TCP connection might already be dead. 11. DLEP Data Items Following is the list of core Data Items that MUST be recognized by a DLEP compliant implementation. As mentioned before, not all Data Items need be used during a session, but an implementation MUST correctly process these Data Items when correctly associated with a Signal or Message. Is "skip over or ignore" a valid way to "correctly process"? I think so, but this might not be obvious from the text as written. In 11.1: Text: UTF-8 encoded string of UNICODE [RFC3629] characters, describing the cause, used for implementation defined purposes. Since this field is used for description, implementations SHOULD limit characters in this field to printable characters. Implementations receiving this Data Item SHOULD check for printable characters in the field. Checking for printable Unicode characters might require keeping an up-to-date table of which Unicode characters are valid and are printable. This seems like a rather high bar to implement, I suspect implementations wouldn't bother. I suggest either deleting the last sentence or downgrading it to MAY. 11.4. Peer Type Peer Type: UTF-8 encoded string of UNICODE [RFC3629] characters. For example, a satellite modem might set this variable to "Satellite terminal". Since this Data Item is intended to provide additional information for display commands, sending implementations SHOULD limit the data to printable characters, and receiving implementations SHOULD check the data for printable characters. As above.
For the Latency and Relative Link Quality metrics, it seems like allowing their measurement methods to be implementation-dependent reduces their usefulness. If two different implementations calculate these in different ways, then the results may not be comparable. Are these not meant to be compared between different destination implementations?
linda dunbar performed the opsdir review
draft-ietf-6lo-dect-ule
One tiny comment: This sounds like a summary of what's specified in TS102.939-1 and therefore should probably not use normative language in this doc: "In DECT protocol domain the PP SHALL specify the <<IWU- ATTRIBUTES>> in a service-change (other) message before sending a service-change (resume) message as defined in [TS102.939-1]. The <<IWU-ATTRIBTES>> SHALL define the ULE Application Protocol Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP sends a service-change-accept (resume) that MUST contain a valid paging descriptor. The PP MUST be pageable. Following this, transmission of IPv6 packets can start."
section 3, last para: "PP node MUST NOT play the role of a 6LoWPAN Router (6LR)." I reckon that's a bogus MUST NOT. I think what you mean is that this spec doesn't define how a PP can be a 6LR. But a bit of h/w and s/w can clearly do both no matter how many MUST NOTs we write. (That may be a difference to the usual DECT setup, not sure.)
I agree with Alissa's comments. Otherwise, I just have a few nits: - Abstract: Please expand DECT. - section 1: The section could benefit from some paragraph breaks. - 3.2, first paragraph: s/ "implements already fragmentation"/"already implements fragmentation" -- 4th paragraph: s/"PP each have"/"each PP has"
Robert Sparks' Gen-ART review comments would deserve some discussion, to make sure that we've addressed all comments received during the last call period.
3.1. Protocol Stack In order to enable data transmission over DECT ULE, a Permanent Virtual Circuit (PVC) has to be configured and opened between FP and PP. This is done by setting up a DECT service call between PP and FP. In DECT protocol domain the PP SHALL specify the <<IWU- ATTRIBUTES>> in a service-change (other) message before sending a service-change (resume) message as defined in [TS102.939-1]. The <<IWU-ATTRIBTES>> Typo: IWU-ATTRIBUTES
I support Alissa's comment on privacy The SecDir review didn't get a response as far as I can tell. Simon had a question and a nit. I think the draft is okay on those points, but a response for the review would be good. https://mailarchive.ietf.org/arch/msg/secdir/3E1g-Ccfeq6U0fWcxc5kQ3FL_3w
I really appreciate the authors taking time to provide this much background for their specification. I did finish with some questions and comments, but if I understood the technology better, I'd be balloting Yes. Could I suggest replacing "an elderly pendant (brooch)" with "a pendant (brooch) for the elderly"? Because I was already picturing a very old brooch, I also misread "Generic Access Profile" as "Geriatric Access Profile" further down the page, but there's nothing you can do to fix that ;-) In this text, The used application protocol is negotiated between the PP and FP when the PVC communication service is established. I think you can delete "used", unless "used application protocol" is a term of art for DECT-ULA. In this text, A FP is assumed to be less constrained than a PP. Hence, in the primary scenario FP and PP will act as 6LBR and a 6LN, respectively. This document only addresses this primary scenario and all other scenarios are out of scope. Does "all other scenarios" just mean "scenarios where FPs are more constrained than PPs"? If so, that might be clearer. In this text, In consequence, the mesh header defined in [RFC4944] for mesh under routing are not used in DECT ULE networks. the term "mesh under routing" doesn't appear in RFC 4944. Did this mean something like "mesh underlay routing"? But if the point is that the mesh header defined in RFC 4944 isn't used, that's probably all you need to say. In this text, Although the TPUI is temporary by definition, the same value is usually repeatedly assigned to any given PP, hence it seems not suitable for construction of IID, see [I-D.ietf-6lo-privacy-considerations]. is this saying Although the TPUI is temporary by definition, many implementations assign the the same value repeatedly to any given PP, hence it seems not suitable for construction of IID, see [I-D.ietf-6lo-privacy-considerations]. ? This may be my own lack of knowlesge at fault, but I'm not sure I understand this text, It is expected that the LOWPAN_IPHC packet will fulfil all the requirements for header compression without spending unnecessary overhead for mesh addressing. I'm guessing that the point is that you don't have to put the mesh header in, to make header compression perform acceptably. Is that it? I think The DECT ULE implements already fragmentation and reassembly functionality, hence [RFC4944] fragmentation and reassembly function MUST NOT be used. should s/implements already/already implements/ Probably for my own education, but in this text Globally uniqueness of IID in link-local addresses are not required as they should never be leaked outside the subnet domain. if those addresses are leaked, does IPv6 Duplicate Address Detection prevent the obvious problems? Could you add a few words explaining why The DECT MAC layer broadcast service is considered inadequate for IP multicast. so the reader isn't left to guess?
(1) draft-ietf-6lo-privacy-considerations says: "Specifications should make sure that an IPv6 address can change over long periods of time. For example, the interface identifier might change each time a device connects to the network (if connections are short), or might change each day (if connections can be long). This is necessary to mitigate correlation over time." This document doesn't seem to provide any guidance about supporting the ability to change an IPv6 address. At least for non-link-local addresses, I think it would make sense to encourage the use of address generation schemes that align with the recommendation above given expected deployment scenarios. (2) draft-ietf-6man-default-iids says that the choice of address generation mechanism should be configurable when a mechanism is specified to embed a link layer address in an IID. Is there a reason that doesn't apply here? The document doesn't say anything about it for the link-local case.
draft-ietf-justfont-toplevel
In 5.3, what does it mean that "RFC 6838 [RFC6838] should be consulted on registration procedures."? Is the point that the registration procedures there apply here?
Dale's Gen-ART review comments were very good. Glad to see the fix is on the way.
Note to self: check media type review. Also, the genart comment about fragment syntax should be addressed.
Dan Romascanu performed the opsdir review
draft-ietf-dnsop-maintain-ds
Thanks for writing this and I think its useful for DNSSEC adoption, my DISCUSS is as follows. I have a concern about changing the status of RFC7344 in this document from informational to standards track, especially given that this document builds on, or as I see it updates, 7344. This will surely be raised on the telechat. Especially given I still see gaps in the larger picture, such as: "In this case there is a possibility of setting up some kind of authentication mechanism and submission mechanism that is outside the scope of this document.." for enabling DNSSEC via CDS/CDNSKEY Can you please promote the first 2 paragraphs of the security considerations section to either the abstract or introduction. When reading this document I had almost exactly those words echoing in my head, and having them up front would better set the scene for why this document should exist - since you have written them already.
can you please clarify: "In many people's minds, those two operations carry more risk than the first one." I read this as; 'In many people's minds, those two operations carry more risk than operation 2." There are other nits in this document, but I think Stephen has already identified them.
I agree with Jari's and Terry's respective discusses. I will watch for the outcome of those discussions. Some other minor comments (I've skipped some that other people have already commented on, but I'm sure there's still overlap): - 1.2: It seems like scenarios 1 and 3 are restatements of the same thing. That is, cannot/does-not-want-to seems to count as an operational limitation. -4, 3rd paragraph: "If a validator sees a DNSKEY or DS record with this algorithm value, it MUST treat it as unknown." I suspect that, in the context of "Right now", this is talking about the current state of affairs, rather than defining a new requirement. Thus the 2119 MUST is probably not appropriate. -- 4th paragraph: I think this MUST is also not appropriate. It's part of the definition of algorithm "0", and not a procedural requirement. Editorial Comments: -1.3, first paragaph: "When this document uses the word CDS it implies that the same applies to CDNSKEY and vice verse." I don't understand this sentence. -2, first paragraph: s/influence/performe -2, operation 2: Please expand KSK on first use -2, 5th paragraph: It’s sort of confusing to talk about options labeled with ordinal numbers in a different order than their labels. -3, first paragraph: First Sentence: I'm not sure what "... enable... for the future." means. Does that mean “for the foreseeable future”, or perhaps “indefinitely enable”? -- 2nd sentence is hard to parse. I suggest the following: OLD Thus during the period from the time the child publishes the CDS until the corresponding DS is published at the parent is the period that DNS answers for the child could be forged. NEW DNS answers could be forged during the period between when the child publishes the CDS until the parent publishes the corresponding DS. -4, third paragraph: "Right now, ..." That language will quickly become dated. I suggest "At the time of this writing, ..."
One technical comment: How does the client know that the parent supports the DNSSEC Delete Algorithm and it actually can turn of DNSSEC after a while? What how long is a while? Would it be possible to define a reply message from the parent to the client to confirm that the deletion was understood? One more or less editorial comment: I agree with Spencer that the use of normative language in the security section is odd. All used SHOULDs should be lower case. But I would also recommend to rephrase to give clear guidance, e.g. OLD: "A parent zone might also consider sending an email to its contact addresses to give the child zone a warning that security will be enabled after a certain amount of wait time - thus allowing a child administrator to cancel the request." NEW: "A parent zone may send an email to its contact addresses to give the child zone a warning that security will be enabled after a defind amount of wait time - thus allowing a child administrator to cancel the request." OR: "A parent zone MAY send an email to its contact addresses to give the child zone a warning that security will be enabled after a defined amount of wait time - thus allowing a child administrator to cancel the request."
Agree with Jari, Terry and would like to see the 7344 situation resolved.
Will be following the resolutions of others' DISCUSSes. One more place where normative language seems inappropriate: "Turning off DNSSEC reduces the security of the domain and thus should only be done carefully, and that decision SHOULD be fully under the child domain's control."
Thanks for this document. I have today reviewed both draft-ietf-dnsop-maintain-ds and RFC 7344, and personally find the recommendations and actions reasonable. I do have a similar concern as Robert did in his Gen-ART review, however, in making sure that the change to 7344 is properly highlighted. We should talk about this on the call on Thursday.
I agree with Kathleen that this is useful document. I also agree with her DISCUSS. I wish you could mandate use of S/MIME or OpenPGP for confirmation emails suggested in the document, but this might be too much to ask for.
Overall, this draft seems like a very useful and helpful draft. In reading it, I would like to see some security considerations around the methods in section 3, in particular section 3.2, which is the loosest. Just seeing that the domain has been transferred seems like a risky check to rely on to me. The risks of using these proposed methods should be stated. Thanks.
I understand why most of the 2119 language appears in this draft, but the SHOULDs in this text Users SHOULD keep in mind that re-establishing trust in delegation can be hard and takes a long time. Before deciding to complete the rollover via an unsigned state, all options SHOULD be considered. don't look like 2119 SHOULDs to me. I also note that there's a SHOULD in section 1.2, but 2119 terminology isn't introduced until section 1.4 (easy enough to fix, by moving section 1.4 up, but).
- I support Jari's discuss - but it might be fine to just chat about the 7344 status change, not sure. But that said, I'm balloting yes, as this bootstrapping is definitely needed if DNSSEC is going to prosper. - please check and respond to the secdir review, [1] which overlaps a bit (but not totally) with my comments. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html - 1.3: s/digiest/digest/ - 1.3: definition of RRR isn't clear (enough) - I think you want to define RRR to mean the current public DNS ecosystem maybe, but not sure if there's a subtlety somewhere in e.g. 3rd level and other domains. This might be clearer if you mention the PSL as a way to explain (not define) RRR. OTOH, you don't use RRR later at all, so you could just delete that term entirely and say a parent is typically an entity one above what's in the PSL, but can be lower down the naming hierarchy, e.g. within an enterprise. - section 2: calling operation 2 the "first one" is confusing, maybe re-order for clarity. Oh, and then you later mean "first one" == "operation 1" - so that does need fixing. Or just delete that para. - 2.1: I think you need to say that the acceptance policy for the very first use of CDS requires some out-of-band agreement, or is just done at the whim of the parent based on a possibly unknown policy. Ah, you do say that in section 3 - maybe consider re-doing the split into sections, e.g. make 2.1 be text at the start of 3. - section 3: I think it'd be good to call out the case where the domain is brand-new (i.e. never before existed) and has a CDS from the very first instant. That might fit in to 3.1, but I think it is worth a mention as a) it's a good goal to have (since it minimises the window without DNSSEC to zero) and so hopefully worth supporting and b) there's arguably no additional risk due to the CDS in this case, since the parent is also adding the delegation at the same time and c) it makes for better automation. That said, I'm not sure what s/w changes supporting that'd imply, but since a lot of parent registry code (APIs and such) are likely home-grown today, calling it out here might help ensure that parents don't all e.g. follow 3.3 or otherwise make DNSSEC-from-the-getgo hard or impossible. - 3.4: Do you need to say that the parent in this case ought monitor the child's DNS and react when the right challenge is visible? If it wasn't already done, this section might also be worth checking with some folks working on acme, as they have analysed such cases.
Separate standards action was carried for the RFC 7344 Standards action. Draft 04 moved the status change to the front-matter. Was Discuss: Place holder for the discussion of a standards action for 7344 discussion I'm taking this off agendas until I get an update and the standards action.
draft-ietf-sidr-bgpsec-algs
Just a thought: Would it be useful to add an IESG note saying something like in the sheperd write-up: "[...] there are published references that preceded the filing of the patent, especially those mentioned in RFC6090. RFC6090 notes that its descriptions "may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years."" I know we usuall don't do things like this. But I'm wondering how someone who wants to implement this should figure this out otherwise....?
As noted by Jouni in his OPS DIR review, and acknowledged by Sean Turner > o Section 7 IANA Considerations says on line 192: > "Infrastructure (RPKI) group. The one-octet BGPsec Algorithm Suite” > ^^^^^^^^^ > However, in the following table and text it says nothing about > values 0x10-0xff. Are these unassigned or reserved? This is a bit > confusing since the table lists values up to 0xF (one-nibble). Sigh - that should be: +------------+------------+-------------+---------------------+ | 0x2-0xEF | Unassigned | Unassigned | This draft | +------------+------------+-------------+---------------------+ | 0xFF | Reserved | Reserved | This draft | +------------+------------+-------------+---------------------+
Thanks for your work on this and it's good to hear there are interoperable implementations (after reading the responses to other comments).
- As Randy commented, if the goal is to smallerise the packets, it'd have been nice to use eddsa here but I assume that wasn't practical due to the timing and the number of RPKI elements that'd need to be defined for that? Is that right? Did the WG consider using 25519 instead of p256? If not, is it worth asking, just in case everyone loves the idea more than this? - Documents like this are better with test vectors included or referenced. Couldn't you add those or some pointers to those? - To answer Mirja's point: Anyone who knows RFC6090 knows that it more or less only exists because of IPR silliness. And sadly, even though 6090 only references documents that predate relevant IPR filings by >20 years, even 6090 still got an (IMO also silly) IPR declaration. [1] Sheesh, but whaddya gonna do? :-( Anyway, I don't think there's a need to, or benefit from, adding text here about the well-known situation with ECC IPR that I believe stymied deployment for at least a decade. [1] https://datatracker.ietf.org/ipr/search/?rfc=6090&submit=rfc
Maybe I missed it, but I don't think the document is clear on why new algorithms are needed. Is this specified in one of referenced documents?
draft-ietf-sidr-origin-validation-signaling
- section 2, super-nit: when you say "the last octet ... encodes" that is a teeny bit ambiguous, as it could just about be read to mean that the last octet is a bit mask, leading someone's code to not correctly handle future values >2. So it might be good to be that little bit more explicit that the other 6 bits of that octet are also important, even if they're not defined now. IOW, if a device sees a value 4 in there then it MUST NOT treat that as valid by only seeing zeroes in the two low order bits. (And btw, I assume network byte order is generically understood here too, not sure if that also needs to be stated, probably not, as that ought be generic for encoding integers within extensions I guess.) - section 2: Is "By default, ... SHOULD drop..." correct? I think what you mean is "By default ... MUST drop" as the case for not dropping is not the default. Or, you could say "SHOULD drop except when... " and not have to mention any default. (Note: I'm only questioning the wording here, not the semantics, which seems fine.) - section 6: I didn't read all the references, but is there anything to be said about possible differences in the duration for which one is vulnerable to not yet seeing a revocation for a node that sees this extension, vs a node that does origin validation itself? If a node having seen this extension were to remember the origin for a lot longer than one that does validation itself, then that might be worth noting here, but I don't know how the relative timings might pan out, so not sure. (And apologies if this is covered in the references I didn't check out;-)
draft-ietf-pals-endpoint-fast-protection
- section 5: I'm not sure "revertive" is a useful term here. Seems to me that it's a) admirably obscure, b) maybe inaccurate, as we're not reverting to a previous state here but rather changing paths, and maybe c) it's not clear if we end up with a "fully functional" path after "reverting." But maybe it's an accepted term of art in routing - if so, some reference to where it's well described might be nice. - section 8, para 1: this assumes that "managed by network operator" means "is secure." I think we have examples where not all that happens within a network is under the control of the owner of the network, so I question that assumption. (I'm not now asking for a concrete change as that'd be a major bit of work, but I am as willing as ever to continue to call this out as it appears;-) If you could remove text based on that assumption, that'd improve the document I think.
A few smallish comments/questions: 1) This is no news but there are a lot of acronyms in this drafts which makes it partly hard to read. Some of them are never spelled out, such as PE, CE, RSVP... I would like to propose two changes to support the reader: 1) Spell out all acronyms in the abstract and 2) add a glossary. Further you could maybe also define some terminology at the beginning such as 'protector'. 2) This sentence/use of acronym is confusing: "In Figure 1, the IP/MPLS network consists of PE and P routers." NEW: "In Figure 1, the IP/MPLS network consists of four PEs and two routers P1 and P2." 3) I don't fully understand this part in sec 4.1: "Normally the router will attempt to forward PW packets in a load balance fashion over the ECMP set. When the link fails, if the router reroutes only the portion of traffic originally traversing the link while letting the rest of traffic remain on the other ECMP branches, it will create a situation where the egress CE receives traffic from both the primary PE and the backup PE. " If you have two ECMP branches, why don't you simply use the other one for all traffic? Isn't this the kind of protection your are discussing? Or are you assuming that this note somewhere on the PW does not apply this backup strategy? 4) Do you have references for mechanisms described in section 5? One high level comment: I was wondering while reading the whole time if this should be informational or standards track. Was there any discussion in the wg? Are there implementations?
Sections 6.4.1 and 6.4.2 The Ingress and Egress PE Addresses are encoded as 4 byte fields. How is this expected to work with IPv6 addresses for the PEs?
I support Suresh' Discuss.
Editorial nits (From Sue Hares, part of her OPS-DIR review) 1. Page 10 - style makes difficult reading of sentence (very minor nit). OLD /A PLR MUST Be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional failure detection (BFD) [RFC5880], etc. / NEW /A PLR MUST Be able to detect a failure by using a rapid mechanism, such as physical layer failure detection, Bidirectional failure detection (BFD) [RFC5880], and others/ 2. Page 32 – difficult to parse sentence Old/For Encoding type, 1 is defined for PWid FEC element format, and 2 is defined for the Generalized PWid FEC Element format [RFC4447]./ New/ For type encoding type, the following two values are defined within this document: - Type 1 for PWid FEC element format (see section 6.4.1.), and - Type 2 for Generalized PWid FEC Element format [RFC4447
Minor: 1) The details in Figure 11 on p. 22 don't look quite right. There is no forwarding state shown on PE4 to handle the incoming labels of 2000 (P3's outgoing label of bypass tunnel to PE4) or 3000 (P2's outgoing label of bypass tunnel to PE4). Either there should be additional forwarding state on PE4 that says to pop 2000 (or 3000) and identify a context label space - or PE4 should have allocated the context label 999 to the bypass tunnels from P3 and PE2. I see the same issue in Figures 12, 13, and 14. Is there a detail or explanation missing?
draft-ietf-6lo-dispatch-iana-registry
Rick Casarez <rick.casarez@gmail.com> provided the opsdir review
draft-ietf-6man-default-iids
- (used to be a discuss, just not a great one;-) Is this clear enough that it is not replacing temporary addresses, and in saying when one ought use those vs. when one ought use 7217? I'm not sure TBH, but, for me, this text reads a bit too much as "use 7217 and not temporary addresses" except for in the place where it says "For example, this document does not change any existing recommendations concerning the use of temporary addresses as specified in [RFC4941],..." So my question is: does this document need more clarity as to when to use 7217 and when to use 4941? I suspect it probably does need a more clear statement about that, if we think we can reach consensus on what that ought say;-) - section 3: is it correct to say "In particular, this document RECOMMENDS that nodes do not generate stable IIDs..." or do you really mean that nodes SHOULD NOT emit packets with <those> in source addresses? IOW, do you mean that nodes SHOULD NOT respond to packets addressed to addresses using stable IIDs? I'm not clear from the text, but am fine with either though I guess that could cause a problem somewhere maybe.
Minor editorial comment: OLD: Stable address: An address that does not vary over time within the same network (as defined in [RFC7721]). NEW: Stable address: An address that does not vary over time within the same network (consistent with [RFC7721]). Justification: This is not the exact same definition.
Sarah Banks <sbanks@encrypted.net> performed the opsdir review.
draft-ietf-appsawg-file-scheme
I also support Stephen's Discuss (which is pretty much "we need to explicitly decide whether we can live with this", as I understand it).
'not' missing? s/It would be impossible for this specification to list all such significant characters and device names. /It would not be impossible for this specification to list all such significant characters and device names. /
- I support Stephen's DISCUSS - Section 5: "Implementers MUST research" and "Care MUST be taken" both seem like requirements on people, not on implementations. Furthermore, "research" and "taking of care" are vague in terms of expected results. Can these be recast into concrete expectations of implementation behavior?
I believ GenArt and SecDir nits were addressed.
I support Stephen's DISCUSS.
I haven't heard the details of Stephen's Discuss.
Appendix C: this spec and the whatwg web page may or may not be in conflict. I think this may be the first PS that we've produced where that fact finally hits that fan - is that right? If not, then I'll clear as we'll already have decided there's nothing to be done about odd behaviour with "competing" specifications for the same thing (that thing being RFC3986). If this is the first time we've gotten to this point, then I think the IESG ought explicitly decide that we are going to live with what we all know is a pretty crap situation where different implementers (web vs. non-web basically) supporting various kinds of URL/URI are liable to end up doing different and potentially non-interoperable things. (There is no action required from the author. For the IESG - we discussed this a couple of years back, but there have been some personnel changes since and I forget if the current set of ADs are or are not up to speed with and ok with this.)
I support Stephen's DISCUSS.
Zhoutianran <zhoutianran@huawei.com> performed the opsdir review.
draft-ietf-core-http-mapping
Well written doc! Thanks!
Thanks for handling my DISCUSS points. OLD Comments below. I didn't check 'em vs. the latest draft. --- Generally, I'd have been happier if this document went more towards reducing the attack surface and seemed less keen on being more flexible. I assume though that the WG considered that. (Some specific places that occurred to me are noted below.) I also agree with Kathleen's discuss. - 6.1: "free to attempt mapping a single Accept header in a GET request to multiple CoAP GET requests" - does that provide a potential way to DoS (e.g. battery depletion) devices in the constrained network? If so, would a warning be useful? E.g. to limit the number of times a given media type is attempted. - 6.1: What "other forms of access control" do you mean? - 6.2: This looks like it allows too large an attack surface and maybe you ought default to denying - 6.5: Transcoding bugs galore! Given the history of bugs in transcoding libraries shouldn't you recommend some caution here? And are there forms of zipbomb that might cause problems? - 8.2: The presentation of the formula is not clear to me. You say "reduces M_R iff..." but that's not a clear "method to decide" as promised. - 10.3: In practice, what does "other means" mean in "This recommendation may be relaxed in case the destination network is believed to be secured by other means." ?
Thanks for addressing my DISCUSS and COMMENTs.
Thanks for addressing my discuss!
Previous DISCUSS point: One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have the new FETCH/iPATCH/PATCH methods (draft-ietf-core-etch)? Should we expect an update document for the new mappings? Don't we need at least a reference to draft-ietf-core-etch, expressing it's not covered? The point has been discussed, so moving to a COMMENT. I trust the responsible AD to take the right action. Regards, Benoit
Thank you for addressing my discuss points with the proposed text. I'll follow along with Stephen's discuss as he picked up on some other important points.
Thanks for addressing my Discuss and comments. For what it's worth, I also like the changes you made to address other feedback, too.
This document is returning as Proposed Standard (it was Informational earlier).
מנחם דודג' <menachemdodge1@gmail.com> performed the opsdir review
status-change-rfc7344-from-informational-to-standards-track
s/was be widely accepted/is widely accepted
I couldn't parse "The methodology described in RFC 7344 was be widely accepted and deployed;" without guessing ...
draft-ietf-dprive-dnsodtls
Thanks for the careful treatment of transport topics in this specification.
Regarding the shepherd write-up: There is no requirement for an implementation section. There is a recommendation to have one, to track implementations efforts during the draft's live-time, but such a section is usually removed on publication as RFC as this information easily out-dates. There is another recommendation to have a section explaining the goals and/or next steps after the end of a (successful) experiment. I personally don't think this is required here, given that I understand the experiment is to figure out if this will be adopted (given there is stable reference). One small question on the text in the draft: "For the client, state should be destroyed when disconnecting from the network (e.g., associated IP interface is brought down). " Does this mean all state including state used for session resumption?
Update: Looks like the address for Dan Wing needs to be updated. -1: Is TCP head of line blocking considered a problem between the client and cacheing resolver? Otherwise, between that and the potential to use TCP fast open, the motivation for not just using TLS seems weak (which may not be a problem for an experimental RFC.) - 3.1: "DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. " Am I correct to assume that this requirement is really about clients and servers that do not implement this spec? While I see the point, how would such a client or server even know about the restriction?
Under which conditions do we know that this experiment will be successful? Anything worth nothing? As an example of a similar RFC, see https://tools.ietf.org/html/rfc7360#section-1.3
I have two discuss points to chat about before I ballot yes for this: (1) I think it'd be good to make the nature of this RFC clear in the document, so that folks don't get confused and implement this now, when we think they ought be using TLS for stub to recursive privacy. I'd suggest maybe adding a note here (possibly an IESG note, or just more text before 1.1, whatever), that says something like: "This DTLS solution was considered by the DPRIVE working group as an option to use in case the TLS based approach specified in RFC7858 turns out to have some issues when deployed. At the time of writing, it is expected that RFC7858 is what will be deployed, and so this specification is mainly intended as a backup." Note that while text like that may also end up in the profiles document, I still think it may be useful here as well. (2) Section 4: No mention of OCSP stapling? And come to think of it, how would non-stapled OCSP even work? And since I've now thought of it, how will OCSP work with RFC7858? Does this (and 7858) need to mandate stapling or no revocation checking via OCSP at all? (Apologies for not asking about that when we were processing 7858;-)
- 3.3: What does "of the order of several seconds" mean? If you mean O(10s) then why not say that? - 3.3: Is figure 1 really needed? There's no longer any meaningful reference to it from the text. (I forget if there once was.) - To try answer Benoit's comment: I think that this is a part of the overall DPRIVE experiment, so it's a little hard to say exactly how this document alone constitutes a useful experiment. But see also my discuss point#1.
Eric Vyncke (evyncke) <evyncke@cisco.com> performed the opsdir review.
draft-wilde-json-seq-suffix
Is it really needed to copy the whole security considerations section of RFC7464 in this doc? And why was this not registered within RFC7464?
-4: Would it make sense to add something like "..., or any IESG designated successor." to the contact? The ART merger has recently shown that even area WG mailing lists do not live forever. -5: I share Mirja's curiosity about why the security considerations from 7464 were copied rather than just referenced.