IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-05-05. 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:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
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:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
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
3.4.3 For action
Telechat:
1037 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
7. Working Group News
Amy: retreat next week; formal telechat two weeks
Amy: opening registration almost immediately for IETF96
Mahesh Jethanandani: what is status on ?? document
Michelle: waiting on expert review
Amy: for retreat, you can get silver-line from airport
Kathleen: cab will probably be fairly cheap
Ben: silver-line is said to be free
1046 EDT Adjourned
(at 2016-05-05 06:02:33 PDT)
draft-ietf-idr-add-paths
Two quick comments: 1) Section 6 says: „The applications are detailed in separate documents.“ Does this doc already exists? A reference would be good! 2) One clarification question: When a path with a new identifier is advertised this actually does not mean that these two paths are different, right? Some one could advertise the same path twice with different identifiers, right? Should this be explicitly mention somewhere?
1. I'd like to see the security considerations explicitly state that this could result in a denial of service attack. The resource consumption is stated nicely, but it would be good (following RFC3552) to state the type of attack. "This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. As a result, multiple paths for a large number of prefixes may be received by a BGP speaker potentially depleting memory resources or even causing network-wide instability." Adding something like: "This could result in a denial of service attack." 2. Change the last sentence of the security considerations section in light of the first paragraph to something like: From: This document introduces no new security concerns in the base operation of BGP [RFC4271]. To: Security concerns in the base operation of BGP [RFC4271] also apply.
- section 2: This bit wasn't entirely clear to me: "A BGP speaker that re-advertises a route MUST generate its own Path Identifier to be associated with the re-advertised route." It wasn't clear to me if that means it's disallowed to use the same path identifier or not when re-advertising. If it's not allowed that'd seem to warrant a "MUST NOT" statement, or to say that the path identifier re-advertised MUST be different from that in the received advertisement - "it's own" doesn't quite say the same to me. - section 5: I wasn't clear what happens in the following case. Alice advertises prefix-A with no path identifier, then prefix-A with some path identifier. Next Alice withdraws prefix-A with no associated path identifier. What happens when I get that sequence? (It may well be clear for those readers who know more about BGP.) - What is "bestpath"? If that's defined elsewhere a reference would be good. (A quick duckduckgo only showed me Cisco specific answers for bestpath, but others for "best path.") - Section 5 (last para): what would "special care" here mean? If that'd be clear to relevant readers, that's fine.
Was also wondering about "bestpath."
as far as I'm concerned this documents the way it's deployed and used today so there's no reason it should go forward.
draft-ietf-bfd-seamless-base
Thank you for addressing my Discuss concerns. I look forward to the updated draft.
Section 3: This sentence is not clear. Which one of the following Options (1&2) do you intend? I am guessing 2, but it may make sense to clarify in either case. Current: Once the above setup is complete, any network node, having the knowledge of the S-BFD discriminator allocated to by a remote node to remote entity/entities Option 1: Once the above setup is complete, any network node, having the knowledge of the S-BFD discriminator allocated to it by a remote node to remote entity/entities Option 2: Once the above setup is complete, any network node, having the knowledge of the S-BFD discriminator allocated by a remote node to remote entity/entities Section 7.2.1. Responder Demultiplexing The last step in section seems to be pointing to the initiator packet transmission. Shouldn't this point to the responder procedures (Section 7.2.2) instead? "Chosen reflector BFD session SHOULD transmit a response BFD control packet using procedures described in Section 7.3.2."
Thanks for addressing my comments! I'll check the updated version next week (after the telechat).
DISCUSS cleared based on proposed edits by Carlos. Thanks for addressing it!
Thanks for addressing my prior discuss comments in the updated draft, noting them here to check before approval. This should be pretty easy to address. In the security consideration section, the following recommendation appears: o SBFDReflector MUST NOT look at the crypto sequence number before accepting the packet. Could you please add text to say what happens (what attacks are possible) if this is looked at? There is nothing to stop the crypt sequence number from being looked at, right? Is there a way to actually prevent that?
- Section 11: I've had discussions with people from time to time about BFD and security. I think I've heard the claim made that authentication was too expensive. (Note: I am not saying that I accept that as a valid claim, but that's a different issue:-) Anyway, wouldn't the same issues apply here if they do to classical BFD? If not, great, and I'll quote you next time someone says crypto is too expensive. But if such claims are also to be made here, then why would you be specifying something that will not be used? - Do the implementations that are in-progress implement the BFD authentication schemes for S-BFD? - Why not recommend that the weaker options from rfc5880 not be used? At least saying to not send passwords in clear over networks would be a good thing. - This document could do with an editing pass. There are quite a few minor grammatical issues that make this a harder read. I guess the RFC editor will fix those though, and they're non-fatal, but seems like a pity to not have done that already.
victor kuarsingh performed the opsdir reivew.
draft-ietf-bfd-seamless-ip
Thank you for addressing my discuss concerns. I look forward to the updated draft.
Section 5.1, 6.1: The IPv4-mapped IPv6 prefix for the IPv4 loopback range 127.0.0.0/8 is incorrect. It is currently written as 0:0:0:0:0:FFFF:7F00/104. It should instead be 0:0:0:0:0:FFFF:7F00:0/104. Sections 5.1, 6.1: The document just talks about the TTL field being set to 255. It does not talk about the Hop Limit field for IPv6. I would assume you want to do the same for IPv6 packets as for the IPv4 packets. Can you include the Hop Limit as well if you want the same behavior for IPv6. I have two suggested forms of changes. Pick whatever works better for you. OLD: TTL field of the IP header SHOULD be set to 255 NEW: The TTL/Hop Limit field of the IP header SHOULD be set to 255 (or) The TTL field of the IPv4 header or the Hop Limit field of the IPv6 header SHOULD be set to 255
This part is unclear to me: "It is, however, possible for an SBFDInitiator to carefully set "your discriminator" and TTL fields to perform a continuity test towards a target, but to a transit network node and not to the target itself. [...] This also requires S-BFD control packets not be dropped by the responder node due to TTL expiry. Thus implementations on the responder MUST allow received S-BFD control packets taking TTL expiry exception path to reach corresponding reflector BFD session." You basically perform a traceroute with (S-)BFD, right? Why do you need the last sentence? Wouldn't it be okay, if the packet get dropped by the responder, to simply re-send with a higher TTL?
Thanks for addressing my DISCUSS point as well as my comments.
Elwyn Davies raised a question about why it is reasonable to require special-case TTL expiry treatment. Carlos Pignataro had a response relating to existing practice with similar treatment. Could that explanation/response and the logic why this is reasonable be added as a note to the document?
Just a couple of small things. I'm pretty sure I know why * UDP destination port MUST be set to a well-known UDP destination port assigned for S-BFD: 7784. * UDP source port MUST NOT be set to 7784. the UDP source port has this restriction, but it might be helpful to people who can't guess, if you could add a phrase explaining why. We were all new protocol designers once. It's a small thing, but BFD Chairs <bfd-chairs@tools.ietf.org> we're phasing out @tools.ietf.org in favor of @ietf.org, aren't we?
Ron Bonica Performed the opsdir review.
draft-ietf-roll-applicability-ami
I have two things I'd like to chat about, given that these applicability documents are where the roll WG has iirc said it'd address security and privacy issues with RPL: (1) 7.1.7: Don't you need to turn that "may not need" around and say that AMI deployments of RPL REQUIRE implementation (and maybe use) of link layer and higher layer security features? (You almost say that in 9.3 I think, so it'd maybe be good to be crystal clear. (2) Why are there no privacy considerations? I think this document needs that. For example, an AMI mesh based purely on link layer security could be a total privacy nightmare. And part of that is down to RPL - if I can cause lots of folks' traffic to be sent to me, that is RPL's issue. That I can then see the application layer content is not RPL's fault, but is still relevant. I think this section is important to include because the authors here are presumably the ones who know the application layer information. And the sensitive information might not only be readings, it could include packet size, if larger packets are caused by activity such as turning on heating, then larger packets indicate presence and smaller ones absence, depending on weather. I am also concerned that there may be privacy issues arising from the various identifiers in use here. Did the WG consider these issues and their potential impact on how it is or is not safe to use RPL? (While the analysis might sound complex, I'd bet that not much new text would be needed, but who knows until the analysis has been done.)
- 1.3: what's the 3rd bullet mean? It's worded very ambiguously. With s/(vs. non-storing)// it'd be clear. - section 3: "a potentially significant portion of which is taken up by protocol and encryption overhead" seems overstated to me - are there numbers to back that up? - 5.1, last sentence: why is it important to note that? explaining would be good - 7.2.3: I don't get what you're telling me here that assists in security or interop? - section 9: please provide references to back up the assertion that "many available security mechanisms are not practical for use in such networks" for some relevant security mechanisms. The problem is that such assertions are used to justify doing nothing at all so they ought not be blithely made. - 9.1: "are unique per device" etc is the only sensible thing and would be nice if always true, but that is often not the case - why state what's known to not be true? Or are you trying to say something else? - 9.2: "it is replaced" - again that's not true, only devices known to be compromised would be replaced, which is by no means all compromised devices - 9.3: "already existing" - you really should have a reference there.
Section 1.2: Required reading - Why is the item [surveySG] in required reading not part of the normative references? Section 1.3: Please expand RPL before first use and add a reference to RFC6550 Section 2: Is this section really required? Seems like a summarization of the RPL RFC. At least consider removing the part that starts with "RPL was designed to meet the following application requirements:" and mentions a list of requirement RFCs. This list does not seem relevant here and is also covered in the RPL spec itself. Section 4.1: This does not sound right. Isn't the periodic meter read traffic going the other direction? " The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads," Section 7.4.1: Please add a reference the trickle algorithm at first use. e.g. "Trickle [RFC6206] was designed to be..."
It's been covered enough already, but I also agree with Stephen's discuss points.
I support Stephen's discuss points and would also like to see more on privacy.
I support Stephen's DISCUSS point #2.
draft-ietf-avtext-sdes-hdr-ext
This is a very clear and well written doc. Thanks. Two minor comments: 1) The calculation for the number of transmission N seems slightly over-complicated: "N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss." Does a new participant already know the loss probably e.g. at the time of joining? Is it correct that if it is assumed to be p=0 that one will send the extension header only once? Should there be a minimum...? 2) Should this doc also register MID?
I'd like to check if there's a small hole in the security/privacy properties here. If there is I hope that a little re-wording will handle it. You say: (1) "In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected." And then you say: (2) "The security level that is applied to RTCP packets carrying SDES items SHOULD also be applied to SDES items carried as RTP header extensions." My concerns are that the SHOULD in (2) isn't really well motivated (for me) - you just seem to say that someone who doesn't follow the SHOULD has to say why, but I don't think that's likely a run-time concept. Secondly, (1) doesn't say that the new stuff has to be protected in the same way, e.g. with the same endpoints having the keys, and not e.g. where the RTCP data has e2e protection but the new header field just has hop-by-hop protection. Are my concerns justified? (If not, that's fine you'll tell me and we're done:-) If these are justified concerns, I think we can easily get around them by (a) closing that potential loophole in (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better specify an exception to the SHOULD that makes sense at coding time or at run time.
- So this one confused me for a bit but I was thinking about RFC4568 - shame about that acronym collision;-) It'd have helped this reader to say that this is not about sending keys in header fields:-) But I'm probably not the intended reader, so it's fine that you didn't. - I wonder if confidentiality protection of these header fields is likely? Is that more or less likely to be deployed than some security for RTCP? If there's a significant difference then I think that ought be called out. Just pointing at rfc6904 doesn't seem entirely sufficient to me if nobody ever does it. - Has someone done an analysis of the privacy implications of moving values from one context (RTCP) to another (RTP) over the range of likely deployments? Note: I'm not asserting that there is a significant privacy exposure here, I don't know if there is or not. So I'm just asking if folks have thought about that and e.g. whether or not some data exposed in this header field could allow easier re-identification or correlation or some similar and possibly subtle privacy issue.
Editorial OLD: First, some requirements language and terminology are defined. The following section motivates why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information. NEW: First, some requirements language and terminology are defined. The section 3 motivates why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information.
The first mention of UTF-8 needs a reference. I am agreeing with Mirja about registering MID, as the document argues that it would be a good idea.
I too was confused about why MID was not being registered here, but then saw that it is being registered in draft-ietf-mmusic-sdp-bundle-negotiation. I think the text in Section 3 should make this more clear. I also gather that in some previous version of this draft it may have been registering both, and so there is language in 5.2 and 5.3 ("Initial assignments," "SDES Items") indicating that multiple things are being registered. I think these should be made singular.
think these were addressed by 06 I have reviewed this document (draft-ietf-avtext-sdes-hdr-ext-05) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I am not an expert on the details of RTP thus treat my comments are not really on the technical side of the document. I found the document fine and have no concerns with it. The IDnits comments can be ignored. They are to be fixed by RFC editor when the RFC numbers are known. I have few minor comments: o Line 180 at the beginning of the paragraph starts “That document also..” Since this is the start of the new paragraph I would recommend setting up the context and explicitly say what “that document” is. o Line 304 "extension word aligned, thus in total 36 bytes.” seems to assume a word is 32 bits. Due historical reasons to avoid confusion I would explicitly state that a 32 bit alignment is what ‘word aligned’ means. o Line 458 "shall be applied, i.e. discard items that can be determined to be” ^^^^^^ although it is not strictly required but I would use the familiar uppercase format here and probably also use more typical MUST here.. - Jouni _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-l2tpext-sbfd-discriminator
draft-ietf-bess-multicast-damping
- A nit in section 3: just because simulations show X does not mean that X will happen in the real world - is there any other evidence that "using this technique will efficiently protect..."? I don't mind if there isn't but perhaps s/will/is hoped to/ or similar might be a good idea if not. - The secdir review [1] called out a few more nits. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06533.html
Perhaps Joel Halpern's comment from the Gen-ART review might be something to consider as an edit: > Given that section 6.2 says that this applies to Ethernet VPNs [RFC7117], it would seem useful to mention this in the introduction.
Some questions from Bert, part of the OPS directorate review. Question(s): - top of page 11: The choice to implement damping based on BGP routes or the procedures described in Section 5.1, is up to the implementor, but at least one of the two MUST be implemented. In the perspective of allowing damping to be done on RRs and ASBRs, implementing the BGP approach is recommended. Did you mean RECOMMENDED uppercase, or is the lower case intentional? I would think uppercase because in setion 7.1 it is stated/claimed that these procedures can be enabled on ASBRs and Route Reflectors. And in order to make this claim, the better be implemented, no? - section 7.3 2nd para: This section proposes default and maximum values, conservative so as to not significantly impact network dimentioning but still prevent I tried to find the work "dimentioning". But difficult to find. Does it mean the same as "domensioning"? From some description I get that impression, but I am not sure. Maybe it is just my poor command of English that causes me troubles here? nits: - page 3 towards bottom: of C-multicast routes". This specification provides appropriate detail on how to implement this approach and how to provide control to the operator, and for this reason, in an update to [RFC6514]. I guess s/in/is/ ?
draft-ietf-bess-pta-flags
I do not suggest a change to the draft, but I am curious why the "Additional PMSI Tunnel Attribute Flags" registry needs a standards-action policy. It's pretty obvious why for the main flag registry, due to the small value-space. Are people concerned that the Additional flag will also run out of space? Or that people will define "bad" or non-interoperable extensions?
Not important but why is the Extension flag bit 1 and not bit 0?
Section 2: * Some of the MUST and MUST NOT requirements are stated on the message itself without stating the sender side rules. e.g. The Additional PMSI Tunnel Attribute Flags Extended Community MUST NOT be carried by a given BGP UPDATE message unless the following conditions both hold: It would be far more useful to state this as a sender rule e.g. The sender of a given BGP UPDATE message MUST NOT include an Additional PMSI Tunnel Attribute Flags Extended Community unless the following conditions both hold: * The following text seems to be redundant as there is a receiver rule that verifies exactly this. What exactly is the intent of this text and who is expected to adhere to/enforce it? If a given BGP UPDATE message is carrying a PMSI Tunnel attribute, but is not carrying an Additional PMSI Tunnel Attribute Flags Extended Community, then the Extension flag in the PMSI Tunnel attribute MUST be clear.
The discussion resulting from the secdir review [1] lead to some suggested changes that haven't yet been included in an update. This is just to remind ourselves about that. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06525.html
Can you please clarify how extended flags are encoded on the wire? I don't think this is clear from the document.
draft-ietf-v6ops-host-addr-availability
While I am afraid the NAT66 cats are forever out of their bag, I am still glad to see this draft. Section 7: I _think_ the point of this section is to suggest that we cannot reasonably estimate an upper limit. But if it says that explicitly, I missed it. (I fear a careless reader will walk away thinking "20" is a good limit) Section 8: s/RECOMMENDED to not impose a hard limit/NOT RECOMMENDED to impose a hard limit/
(I'm getting a bit outside my area of expertise here, but since I've been playing about with IPv6 recently and am not shy about asking silly questions... :-) - I think you're missing one other reason why people allocate /128's - in a hosting/VPS environment, the hoster might want to avoid VPS's that originate spam using many different source addresses over time so as to attempt to avoid IP address based (bad) reputation accruing to their outbound spam. Personally, I think associating such reputation scores with IPv6 prefixes or addresses is a bit dodgy, but this is I think something that is done in the wild, (no idea how frequently) so would be worth a mention. If you have good arguments as to why such a scheme is a bad idea, that'd be good to include as well. - I was a bit surprised to not see any mention here of ULAs. I've seen one DHCPv6 setup where my laptop was assigned a ULA with a very long lease in the hope of always having that connectivity to local systems that aren't all on the link. But having that plus real global addresses caused glitches as (I think) my OS (ubuntu) wasn't sure which of the addresses to use as the source for what. While I didn't explore what was going on there (I just zapped the lease:-), do you need to say how to handle cases where one has both real global and ULAs on an interface? - I would have liked if you had said that, other things being equal, OSes SHOULD prefer to use privacy addresses as the source address or as a default. Is there a reason to not say that? (Just wondering, I'm not trying to strongly argue that you do.)
Section 3: * What is the term ePDG being used here? Can you please add a reference? The well known term in mobile networks is Evolved Packet Data Gateway that is used for IPsec tunnel termination. That does not seem to make sense here. * Maybe worth adding a reference to RFC7278 (64share) here as an example for "Extending the network (e.g., "tethering")." s/which is only available in 3GPP release 10/which is only available in 3GPP release 10 onwards/ Section 4: It is not clear what this bullet means. Can you clarify? " o Uncertainty, because it is not known in advance if a particular operation function will be available."
Section 3: s/which is only available in 3GPP release 10/which has been made available as of 3GPP release 10/ Section 9.1: - May be better not to presume that operators do things "to avoid liability" - I don't think that particular sentence is necessary here. - I was surprised not to see a note here about interaction between this kind of host tracking and MAC address randomization, which I assume makes tracking harder independently of the whether the recommendations in this document are followed. But is it not discussed because operators who feel they need these kind of logs also prohibit MAC randomization?
I have followed the discussion between Roni Even (Gen-ART reviewer) and Lorenzo: > The intent here is to say that while the DHCPv6 PD RFC uses the words > "requesting router" to denote the DHCP client, is nothing in DHCPv6 PD > itself that requires the PD client to be a router (where, in IPv6, the term > "router" is defined in RFC2460). > So - even though the DHCPv6 PD RFC uses the term "requesting router", a > host can use DHCPv6 PD to receive a prefix as well. The host can pick some > addresses for that prefix for its own use, originate/terminate packets on > those addresses, and not forward packets addressed to any of the other > addresses in the prefix. Personally, I think it would perhaps useful to consider a slight reformulation of the text, given that for things like tethering or virtual machines, hosts essentially become routers.
I think the Complexity mentioned in section 4 should be a security consideration since there are more opportunities for mistakes that lead to data leakage.
This is a well written document which argues well for assigning multiple IPv6 addresses per host.
draft-ietf-avtcore-rtp-circuit-breakers
I just have a nit and a random query... - nit: The abstract says "It is expected that future standards-track congestion control algorithms for RTP will operate within the envelope defined by this memo." That seems both unwise and unlikely to work to me. Unwise in that you're trying to control the future which seems like it'll just generate heat and not light, and unlikely to work since it's not clear to me that any CC scheme can take into account circuit breaker constants configured on a node that may not be known anywhere else. I'd say better would be to say that we hope that future CC algorithms will be consistent with this and leave it at that. However, if that sentence is the product of a bunch of haggling then it's probably better to leave it as-is and I'll just hold my nose a bit;-) (Same sentence is in the intro - same comment.) - query: Assuming people have implemented some or all of this, I wondered if it'd be a good idea to document some of the ways in which those implementations went wrong, i.e. bugs already fixed, especially if there were any that'd result in the circuit not being broken when it ought be. But that's probably too late or better done in some other document for now, so feel free to ignore me.
Many thanks for this work. I expect to ballot YES once we discuss and resolve the issue below. In Section 4.5, I understand the need to base the re-start of the media flow on a human user intervention, but I find it puzzling that this is framed in terms of "restarting the call" rather than "restarting the flow." The recommendation in Section 8 is that senders MUST treat each session independently, but ending/restarting "the call" seems to assume that multiple flows will be treated together. One situation I'm thinking of is one where my audio and video traffic are in separate RTP flows and are routed along different paths for whatever reason. Some network problem is encountered in the video path, triggering a circuit breaker. The "call" doesn't necessarily need to be terminated and re-started, because my audio can continue just fine. This is another case where the application may not want to rely on a human user re-start (if you leave it up to me whether to re-start my video, I'll certainly try to re-start it right away). I think the text in this section needs to be re-phrased to separate the case where a circuit breaker triggering on a single 3-tuple causes a whole call to end (either because the call consisted of a single flow or because all of the flows were encountering congestion and it takes just one circuit breaker to trigger the end of it) from cases where it causes only that flow to be suspended, and reference Section 8 to make it clear that the unit of operation for "ceasing" and "re-starting" is a single flow unless the sender chooses to group flows. Furthermore (and this is not a DISCUSS point but I leave it here since it follows from the points above), the normative recommendation in the first paragraph here doesn't really follow from the discussion of restarting the call. The recommendation is not to automatically re-start until indications are received that congestion has improved, which is different from waiting until a human user re-starts. I think this would be clearer if the normative recommendation came first and the human user case was discussed afterward.
(1) Did the WG discuss BCP status for this rather than PS? (2) Section 4.3: "If such a reduction in sending rate resolves the congestion problem, the sender MAY gradually increase the rate at which it sends data after a reasonable amount of time has passed, provided it takes care not to cause the problem to recur ("reasonable" is intentionally not defined here)." In later sections you explain that thresholds are not specified because they are application-dependent. I think that would be useful to note here too as the reason for not defining "reasonable," assuming that is the reason.
Thanks for working with me on my Discuss.
This is about one point in section 7 (ECN) that I think is wrong but I would like to get some feedback from the authors: "then ECN-CE marked packets SHOULD be treated as if they were lost when calculating if the congestion- based RTP circuit breaker" (also section 5: "The count of ECN-CE marked packets contained in those ECN feedback reports is counted towards the number of lost packets reported") We are currently discussion mechanisms where the AQM in the congested network node sends much more CE markings than one would see loss (when using TCP) for the same level of congestion. When treating ECN-CE similar to loss, such a different behavior could trigger the circuit breaker unnecessarily. Potentially ECN-CE might not need to be considered here at all, because as long as there are (only) ECN-CE marks (and no loss) all data is transmitted correctly to the receiver and therefore there is no need to trigger a circuit breaker. Further also in section 7: "ECN-CE marked packets SHOULD be treated as if they were lost for the purposes of congestion control" This document should not impose any SHOULDs for congestion control as this doc is only about circuit breaker sand therefore the sentence above should be removed.
Few more minor comments: 1) reference [I-D.ietf-tsvwg-circuit-breaker] should be normative 2) How is the loss rate in 4.3 calculated if some (but no all) RR are lost? 3) I don't think that most of the text on congestion control in section 2 (as well as the abstract) is necessary for this doc (but it also don't really hurt)
scott bradner performed the opsdir review
draft-ietf-isis-node-admin-tag
Just a couple of nits: - 4.1, last paragraph: "Each tag SHOULD be treated as an independent identifier that MAY be used in policy to perform a policy action." I think the MAY may be spurious. It seems to be a statement of fact about the tag, rather than an implementation choice. (But this is a borderline case of spuriousness). - 8: In addition to Alvaro and Alissa's comments, remember that RFCs live forever. Statements that other work needs to happen will (hopefully) become dated. Some qualifier like "At the time of this writing..." can help.
Peter Yee's Gen-ART review raised this issue which I agree with. Can this be defined in a more clear fashion? Or is there already a definition somewhere else that I had not seen? Page 5, section 4.2, 2nd paragraph, 1st sentence: The sentence states: "Being part of the Router CAPABILITY TLV, the node administrative tag sub-TLV MUST be reasonably small and stable." If you're going to make this a MUST, you've got to at least give a definition of "reasonably small" and perhaps even "stable" in the context of this specification. As it stands, there's no test for whether the MUST is enforceable or understandable between parties.
Just some minor comments: 1. Section 1. (Introduction) 1.a "This document provides mechanisms to advertise node administrative tags in IS-IS for route and path selection." While route and path selection is an application, that is not what this document does -- that is just one application. 1.b "…the new TLV for carrying node administrative tags…" It's a sub-TLV. 2. Section 2. (Node Administrative Tags): "An IS-IS router SHOULD advertise the set of groups it is part of in the specific IS-IS level." Do you really want to use "SHOULD"? Given that this extension is optional and that configuring the tags is also optional, and that even the CAPABILITY TLV is optional, I think "SHOULD" is too strong. s/SHOULD/MAY or even s/SHOULD/should 3. s/diiferent/different 4. Section 8. (Manageability Considerations): "…[I-D.ietf-isis-yang-isis-cfg]…[I-D.ietf-rtgwg-policy-model]…These two documents need to be enhanced to include the node administrative tag related configurations." I hope that this text means that someone (maybe one of the authors) will work to enhance those other documents before publication (and not later write separate extension documents).
Agree with Alvaro's point #4. This seems like a bit of a weird statement to make in an RFC; if updates to the other documents are expected then maybe this document should say that?
Juergen Schoenwaelder performed the opsdir review
draft-ietf-dime-drmp
I fully agree with all discuss comments made by Ben and Alissa. However, the summary here might be that this information might simply be not very useful for the uses cases described. And there might be other mechanisms that do not require any trust and that can address the uses cases easier and more appropriate such a simply prioritization of a certain application in the request handler/request agent or relative priorities within one application (on sent-out). However, the one part that does actually concern me is: "When using DRMP priority information, Diameter nodes MUST use the default priority for transactions that do not have priority specified in a DRMP AVP." This part seems dangerous and I would proposed to instead basically have to different queues: one if a priority is defined and another one for requests without priority indication to make sure that requests out of the second queue will be served at some point in time and cannot be starved by other low priority requests completely.
Why do you need 15 different priority levels? Wouldn't be two enough for all or your use cases?
I have a few concerns that I think need some discussion. 1) Priority between applications: The fact that agents can apply priority for messages from multiple applications without knowledge of those applications seems dangerous. Let's say application A is a critical infrastructure application, and application B is not. But clients for application B might set requests to have a higher priority than do clients for application A. Further, application B could become a DoS vector for application A. One potential (and likely half-baked) way to mitigate this would be to say that nodes that are not "application aware" can only apply priority among messages for the same application. 2) Priority between clients of the same application: If you have multiple clients for the same application, don't they need to use the same prioritization strategy? How is this to be managed? 3) Out of order requests: The draft explicitly allows agents to re-route and even explicitly re-order messages. Is it safe to have a non-application aware node change the order of messages? 4) I am nervous about the idea that clients and servers would use a generic message priority mechanism to manage the allocation of resources that result from a requests and answers. It seems like that should be based on application specific rules and information. (Now, if the point is that these same AVPs might be used in an application according to application specific rules, that might be okay--but then you might run into issues where application-agnostic agents don't know the difference.)
General: I approached this assuming prioritization would matter only in overload scenarios. But I gather you envision using this in non-overload scenarios? (This interacts with my discuss point about the use of DRMP to prioritize resource allocation that result result from successful diameter transactions.) Use case 5.3 is a bit worrisome in this context. -6, list item 4: Are there really use cases for answer senders to set a different priority on the answer than was on the request? That seems to add quite a bit of complexity. - 6, list item 8: I'm not sure what it means for a client to prioritize answers to it's own requests. -8, "Diameter nodes SHOULD include Diameter routing message priority in the DRMP AVP in all Diameter request messages." : Does that apply to all nodes that touch a request, or just the request originator? -- "Diameter nodes MUST use the priority indicated in the DRMP AVP carried in the answer message, if it exists." The MUST seems odd, since paying attention to the priority in the initial request was only SHOULD. -- "Another is to use the Proxy-Info mechanism defined in [RFC6733].": That probably needs some elaboration.
I disagree with Mirja's DISCUSS point. In Section 6: excuse my ignorance, but how can priority information be conveyed to non-supporting endpoints (in 2 places)? And what is the point,as they don't support the extension? In 9.1: it would be better to just have a table, instead of copying and modifying lots of text. It would be good to have a short sentence saying how this extension affects non upgraded agents.
(1) Given the two key security threats identified in Section 11 -- that authorized nodes can issue requests with artificially high priority in order to get better treatment, and that unauthorized intermediaries can modify the priorities that senders set -- I don't see how it is legitimate to claim that either 5.1 or 5.2 are appropriate use cases for DRMP. The spec seems to assume that this mechanism will only be used in scenarios where nodes and agents have some out-of-band trust relationship established with each other (the shepherd write-up talks about a "trusted environment"), but that is certainly not the case in many disaster and emergency scenarios. If that really is a limitation on the scope of applicability of this mechanism, that should be stated in the document, and those use cases should either be removed or modified to explain the limitations on their applicability. (2) Section 6 says: "The mechanism for how the agent determines which requests are throttled is implementation dependent and is outside the scope of this document." How is a node supposed to determine how to set its priorities if each agent makes implementation-specific decisions about what those priorities mean? I understood the document to be saying that Diameter applications would have to define what he priority levels mean within their own contexts, but then I would have expected the interpretation of priorities amongst all nodes and agents implementing the same application to be the same. (3) Section 8 says: "Diameter nodes SHOULD use the PRIORITY_10 priority as this default value." If the determination of the priority schemes are all application-specific, how is it appropriate for this spec to define what the default priority should be for all applications? Shouldn't applications specify their own defaults?
Section 11 says: "DRMP gives Diameter nodes the ability to influence which requests are throttled during overload scenarios." But the information is not limited to use during overload scenarios, and the spec specifically allows its use for prioritized routing in absence of overload. This should be stated here too.
- OLD: This also recognizes that more work has already taken place for established sessions and, as a result, it might be more harmful if the session update and session ending requests were to be throttled. NEW: This also recognizes that more work has already taken place for established sessions and, as a result, it might be more harmful from a signaling point of view if the session update and session ending requests were to be throttled. - 1. Request sender - The sender of a request, be it a Diameter Client or a Diameter Server, determines the relative priority of the request and includes that priority information in the request. Question: what is the risk of DMRP ending up as the DSCP, i.e. Every end point changes the value to best service, and in the end, it's useless, and uniquely set by the operator.
I'd like to see text clarifying the responses to Ben & Alissa's discuss points.
I agree with Mirja's and Alissa's discusses.
After reading the document and the threads related to the DISCUSSes, I'm ABSTAINing because I can't see how this mechanism can reliably work (even in "trusted environments") as described here.
draft-ietf-rtcweb-alpn
Should I-D.ietf-rtcweb-security-arch be a normative reference, due to the citation in section 4?
- I suspect the term "confidential" as used here will turn out to mislead or confuse some folks. The meaning is clear if one reads the draft, but of course many people will just read some stackexchange answer. It's probably too late to try change that unless someone has a good term beginning with "c" to use for c-werbrtc. The potential for confusion I think will be that the other label might be assumed to not use a good confidentiality mechanism on the wire, so folks might get concerned that e.g. their DataChannel stuff can be read by a middlebox. (I just mention this in case the concern is either new or has been bubbling up in the WG, feel entirely free to ignore me if you want.) - I forget how the screen sharing issue for WebRTC was resolved. In any case, do the handling of screen sharing and c-webrtc interact? Do you need to explain that there's some non-browser "access" (origination really) of media on the screen-sharer's machine? - "clever arrangement of mirrors" - that is a nice way to explain the futility of DRM :-)
Note: There has been no answer to Russ Housley's Gen-ART review comments yet.
I agree with Stephen's comments on the word confidentiality, but can't think of an alternate word. I think text describing how this is limited would be helpful in the introduction. The clearest (at least to me) description of what is meant by confidentiality doesn't appear until the security considerations section.
Please excuse my ignorance (pointers would be appreciated, if this is explained elsewhere): do RTP intermediary need to be updated to understand this spec? If yes, how can you enforce requirements on "c-webrtc"?
draft-ietf-ospf-sbfd-discriminator
draft-ietf-tls-chacha20-poly1305
draft-ietf-tls-chacha20-poly1305
Nit: SHA-256 probably needs a normative reference.
draft-ietf-pals-seamless-vccv
seems like this is package with two drafts on the 5/5 telechat. they could be put together and that would be fine, gi ven this one is largely the values which need to be understood in the context of the other two drafts.
draft-ietf-netconf-yang-library
draft-ietf-idr-route-oscillation-stop
- abstract: use of so many acronyms here is a pity, be good to expand or not use some of 'em - intro: "MED attribute" is not mentioned in RFC4271, at least not obviously enough to find with a grep;-) I had to search for "multi" to figure out that you meant the MULTI_EXIT_DISC thing, so maybe point at 5.1.4 in 4271 to be nice? - intro: It'd also be nice to provide a reference for the "almost all of the known" claim for readers who aren't familiar with such examples. (And I do mean "nice" and not "necessary":-)
Thank you for writing this document on this important issue. I want to recommend its approval as an RFC and will do so shortly, but a Gen-ART review from Paul Kyzivat inspired me to read the document, and I have some comments. I'm not necessarily looking for document changes, but I am looking for some responses to Paul's or my comments, to make sure we all agree that we are doing this right. Specifically, > A detailed description of how these oscillations can occur > can be found in [RFC3345]; the description of how a node would > locally detect such condition is outside the scope of this document. I am not an expert on this topic, but I'd like to understand the nature of such detection algorithms. How hard problem is that? What is required? I'm not looking for specifying or even referring to the algorithm here, but it would be beneficial at least for this reader to understand the nature of the class of solutions referred to here. Are solutions algorithmically computable? Heuristic? Dependent on specific configurations? Vendor solutions exist but aren't documented. > When the ADD-PATH Capability is also received from > the IBGP peer with the "Send/Receive" field set to 1 (receive > multiple paths) or 3 (send/receive multiple paths) for the same <AFI, > SAFI>, then the following procedures shall be followed: > > If the peer is a route reflection client, the route reflector SHOULD > advertise to the peer the Group Best Paths (or the Available Paths) > received from its non-client IBGP peers. Depending on the > configuration, the route reflector MAY also advertise to the peer the > Group Best Paths (or the Available Paths) received from its clients. I am picking this text excerpt as an example. Like Paul, some of this language makes me slightly uncomfortable, and it would be good to understand what the aim is. If the intent is to describe a procedure that can be followed and fully specified, the expectations on the text are different from an informative description of the kinds of things an implementation could do. In the above text, there's quite a lot of imprecision. That may be fine, but I wanted to check that this is the case. For instance, why is a "shall" (and in lowercase) followed by a set of "SHOULD"s and "MAY"s? Is there any guidance on when the "SHOULD"s should be followed? There seems to be thinking behind, could that be documented? What kind of configuration issues affect the decisions?
The abstract and introduction should explain terms that are not commonly used (such as MED). BGP is a fine term to use without expansion.
Jon mitchell performed the opsdir review against 02 I have reviewed draft-ietf-idr-route-oscilliation-02 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I found the document is clear and Ready w/Issues (primarily last paragraph of this review). This is a Informational draft from the IDR WG which describes the necessary set of paths that have to be advertised in order to stop BGP persistent route oscillation due to the MED attribute. Nits/suggestions: Abstract - I don't think it's required to put caveats in the abstract, this is well covered in the introduction and the text, consider removing the last sentence parenthesized content. Introduction - paragraph 2, strike the word clearly, s/"right"/necessary, consider finishing last sentence with "to prevent the condition." paragraph 3, first sentence - s/present/describe (easier to understand due to only one definition) paragraph 4, last sentence - s/is/are Section 3 - consider renaming section header to "Advertise All the Available Paths", even though all is somewhat redundant, it aligns with previous text, internal text, and addpath-guidelines description. Section 4 - paragraph 2 - I let this slip by the first time around but tried to get them to soften the language about intra-cluster metrics versus inter-cluster metrics in RFC 4456, but maybe it's worth softening the language here about it. An obvious alternative topology of using larger intra-cluster metrics than inter-cluster metrics also is sufficient to prevent route oscillation in the case where all BGP NEXT_HOP's are coming from clients in the cluster (so that a large intra-cluster link metric is included in the calculation in either case). This is sometimes deployed by providers that want to ensure intra-cluster links are depreferenced versus WAN links for transit traffic. As simple of a sentence as, or any technique that prefers intra-cluster to inter-cluster clients from the perspective of the same clusters route reflector, would be sufficient to describe what is necessary to prevent oscillation. A reference to RFC 4451 may be useful as well which also discusses MED deployment considerations. Section 5 - add-path guidelines draft seems to be a useful reference here that describes the various implementation approaches of ADD-PATH including the two required to stop MED-induced oscillation? Section 6, last sentence - as an operator, I disagree that what appears to be a recommendation (am I misreading this sentence?) for greater utilizing MED in the decision making process is being done here. MED as is described by this draft often causes more issues than it solves as seems evident by the necessity of this draft. In fact, if the recommendation instead was to flatten MED to the same value everywhere or compare MED's between AS's (an often deployed knob which is not IETF documented AFAIK), you can rule out the case of MED-induced oscillation w/o the necessary enhancements proposed by this document. I believe this is clearly spelled out in RFC3345 as well (see section 2.3 and 3.2). It's not clear to me that this sentence is even factually correct, and would cause a reduction of the number of group best paths that need to be advertised, maybe this is making some wider assumption of how MED's are assigned by the peer networks? Cheers, Jon _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-campbell-art-rfc5727-update
I absolutely fine with this doc and understand that an update of RFC 5727 is needed (especially to update/decouple the SIP change process), but I have a question out of curiosity: Why does ART need dispatch (and define the process in an BCP) while other areas have an area meeting that more or less performs the same task...? I'm probably missing some history on this, but would be curious to learn more!
Note: RFC 5111 was a time-limited experiment.
This document is related to the DISPATCH charter, recently approved by the IESG. For example, my feedback, which lead to the changes at https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-dispatch%2Fwithmilestones-02-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-dispatch%2Fwithmilestones-03.txt, is (I believe, different wording is used) covered under the following text. Nothing in this list prevents existing working groups from directly adopting new work that reasonably fits their charters, nor does it prevent new-work proposals from going directly to BoF meetings when appropriate. For borderline cases, the decision whether new work should start in a dispatch-style group or elsewhere is made by the responsible Area Directors and chairs. Even if the write-up doesn't mention the link with the DISPATCH charter, I trust the authors (current and past IESG members) have double-checked everything.
I want to make sure that this doesn't prohibit direct chartering of WGs without BOFs and without going through DISPATCH. I intend to assume that is the case for some work I am planning.
draft-ietf-i2rs-pub-sub-requirements
I agree with Benoit about versioning (point #3).
I have a couple of points I would like to discuss. Hopefully they can be resolved easily: Are there really no requirements for privacy or integrity protection? Is there an expectation that this mechanism would ever carry privacy sensitive or otherwise sensitive information? - 4.2.5, 2nd to last paragraph: I am surprised to find that, when the receiver is not the subscriber, that the receiver is expected to opt-out. It seems like some form of opt-in or affirmative consent would be needed here.
- General: I support Stephen's DISCUSS -2.2: What is the real scope of this work? Is it expected to supplant the mentioned mechanisms? - 2.3: "We need a new pub-sub technology" The shepherd write up mentioned a goal to use existing technologies. Is the point of this sentence to suggest that is not feasible? - 4.1, 4th paragraph: The MAY doesn't seem right--is this a statement of fact that the subscriber may have to resubscribe, or a requirement of the form that the service MAY force the subscriber to resubscribe? (Be careful with MAYs in requirements language--they imply unexpected things. For example, several requirements say a SUBSCRIBE MAY do something--do those imply that the service MUST allow the subscriber to do it ?) -- 4.2.2, third bullet: The previous section said dampening periods MUST be supported. - 4.2.1, third paragraph: This is a bit ambiguous. I think it means to change the what subtrees the subscription applies to, but could be interpreted to change the subtrees themselves. - 4.2.6.4: Would a mechanism that allowed out-of-order delivery but gave the subscriber a way to reconstruct the order fulfill this requirement? Nits: - The shepherd write up suggests this is standards track. The draft and tracker both say informational. Please update the shepherd writ up. -3, last paragraph: What's the difference between a "Push" and an "Update"? -4.1: A forward reference to the subscription QoS section would be helpful. -- Last paragraph, last sentence: Sentence doesn't parse. - 4.2.8, third paragraph: I don't think that should be a 2119 MAY
Three DISCUSS points, which could be easily resolved IMO. 1. As mentioned on the NETMOD mailing list by Tom Petch, don't redefine the YANG datastore term: > I see that the definition of 'datastores' has cropped up in this AD > Review, as in the e-mail below. > > Meanwhile, draft-ietf-i2rs-pub-sub-requirements-05.txt is in IETF Last > Call and redefines, or recreates, the term for us > > A YANG datastore is a conceptual datastore that contains hierarchical > data defined in YANG data models. It is what is referred in existing > RFCs as "NETCONF datastore". However, as the same datastore is no > longer tied to NETCONF as a specific transport, the term "YANG > datastore" is deemed more appropriate. > > I think that the concept of datastore has been troublesome to those > coming to YANG lately, such as openconfig and I2RS, and that this will > just muddy the waters more, especially as it is tucked away in an > Informational document. If I2RS want to define such terminology, then > it should be in the I2RS Architecture or some such; but IMHO they should > not be defining YANG datastores at all. 2. Maybe I read too much into this (at the time of specifying the operational state in NETMOD) ... A Subscription Service MUST be able support a Subtree Filter so that subscribed updates under a target node might publish only operational data, only configuration data, or both. Proposal: s/Subtree Filter/Filter 3. In the security considerations section Versioning MUST be supported. Versioning of what? Yang push protocol, subscription, transport session, state of of subscription, something else?
- Editorial Based on current I2RS requirements, NETCONF should the initially supported transport based on the need for connection-oriented/unicast communication. s/should/should be - Editorial: A Subscription MAY include filters as defined s/filters/Filters Note: there are multiple instances of filter -> Filter - AND is not a RFC2119 keyword For "on-change" notifications, passing through the Filter requires that a subscribed object is now different that from the previous Push, AND at least one of the YANG objects being evaluated has changed since the last Update. - I always wonder what a MAY requirement means? Example: A Subscriber MAY check with a Subscription Service to validate the existence and monitored subtrees of a Subscription. Or: A Subscription Service MAY send Updates over Best Effort and Reliable transports. What if https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ doesn't address this requirement (I haven't checked), are we good or not?
I support Stephen's discuss points.
I have what I hope are two very easily sorted things that I'd like to chat about: (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we ever have a pub/sub service whose subscribers can pretend to be the service? (2) Don't you need a statement somewhere that commensurate security needs to be provided for pushed notifications as was used for the original subscription? That might be a little hard to phrase correctly but I hope we agree that the notifications ought not be significantly less secure than the subscription.
- I wondered if this was maybe of interest to more than just i2rs, and if so, whether any effort had been made to try figure out if these requirements work for folks who don't care about i2rs? It'd seem a shame to work on this but stop one step short of being appropriately general. (But you probably already checked that I guess.) - 4.2.2, last para: The MUST here seems like it may be quite onerous, in general. Did someone think all of that through? For example, what if the reason for declining is that the Subscriber doesn't have sufficient privilege? Saying what privilege is needed would be a breach of least-privilege. Transient errors may also make this very hard to do well. I'd suggest s/MUST/MAY/ and to also turn the information returned into a hint and not a promise. - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd - the usual terms would be "MUST implement" or "MUST use" which of those does "MUST be" mean? - 4.2.8: when you say fetch... by whom? Is there an implicit requirement in the title of the subsection?
I support Ben's and Stephen's DISCUSSes.
draft-ietf-bfd-seamless-use-case
1) Sec 3.7: This section describes BFD Fault Isolation. It isn't clear to me that the S-BFD base spec has addressed this case at all. More clarification would be nice - either indicating that this use-case wasn't handled or having a small pointer to how it was.
While this document has a security requirement, I believe there is also a risk of misconfiguration: if no handshake is performed, a node might send S-BFD packets to a receiver that does not exists or is not aware of it or sits at a different part of the network that is somewhere else than expected which can overload the network accidentally. Should this be mentioned in this doc (or somewhere else... or both)?
Shouldn't Requirement #10 explicitly state active and passive attacks? That way you cover interception and passive listening too.
draft-ietf-radext-bigger-packets
Minor: A reference to RFC 6613 in the last paragraph of section 1 would be helpful.
Good stuff.
Thanks for a well-written draft!
just use tcp is a perfectly reasonable premise
draft-ietf-i2rs-traceability
Intro: I don't agree that all data retention aspects are out of scope here. They are about as in-scope as log rotation I'd say. I do think it'd be worthwhile noting that if log content contains sensitive data (either security- or privacy-sensitive) then retaining that data for extended durations has a cost, in terms of creating risks if data leaks. While one cannot say here how to evaluate such risks, they do exist and should really be noted. It would also be sensible IMO to say that implementations SHOULD provide a way to purge ancient log content that is no longer needed or useful, but that the definition of when content is no longer needed or useful is out of scope. In saying this I do recognise that much or perhaps even most i2rs log content will not be security or privacy sensitive, but in some cases it can be, e.g. if an operation involved an address that is specific to a user or device carried by a user. In addition, some data retention regimes could impose a requirement to purge log content after a certain duration. I'd say a note about this in the intro or in the security considerations should be a fine way to handle this issue, and to acknowledge that not all data retention issues are out of scope for implementations.
- 5.2: Requested/Applied Operation Data - I would guess this can include sensitive values, e.g. keys/passwords. Shouldn’t you say to at least be careful of those, or perhaps to not log them, or to zero out known sensitive values before logging? - 7.2: how is privacy an implementation detail? - 7.4: What does "being preferred" mean in 2119 terms? Why is one of the three options not mandatory-to-implement?
Section 5.2: Starting Timestamp and Ending Timestamp It is not clear what the terms 32-bit second and 32-bit microsecond mean here as the RFC3339 format seems to be a string representation (e.g. the seconds value will never be more than 59). It may be useful to restate these granularity requirements in terms of number of digits required after the decimal point instead Section 5.2: Entry ID Some more clarity as to how Entry IDs work would be useful. e.g. Is this a monotonically increasing integer? What happens when this wraps? What happens when the log file is rotated etc.
I agree with Stephen's comments though.
I would like to DISCUSS the following point. - From https:/https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-06, section 2.1 From [i2rs-arch], there are references throughout the document beginning in section 6.2. Some specific examples include: ... o section 6.3 notes that when local config preempts I2RS, external notification might be necessary What about the local configuration, https://tools.ietf.org/html/draft-ietf-i2rs-architecture-15#section-6.3 ? Is this logged? From the client address, it seems that local is not covered. Should it be? Client Address: This is the network address of the Client that connected to the Agent. For example, this may be an IPv4 or IPv6 address.
- Syslog rfc5424 Let's make the RFC2119 sentence clear (include the "If", and remove "example") Background: last time I checked (about 6 months ago), RFC5424 was not implemented OLD: If syslog is used for trace log retrieval, then existing logging infrastructure and capabilities of syslog [RFC5424] should be leveraged without the need to define or extend existing formats. For example, the various fields described in Section 5.2 SHOULD be modeled and encoded as Structured Data Elements (referred to as "SD- ELEMENT"), as described in Section 6.3.1 of [RFC5424]. NEW: If syslog is used for trace log retrieval, then existing logging infrastructure and capabilities of syslog [RFC5424] should be leveraged without the need to define or extend existing formats. If syslog is used for trace log retrieval, the various fields described in Section 5.2 SHOULD be modeled and encoded as Structured Data Elements (referred to as "SD- ELEMENT"), as described in Section 6.3.1 of [RFC5424]. - Out of the 3 methods for trace log retrieval (section 7.4), I was expecting the pub-sub to be THE method, and was expecting a MUST requirement. Background: I just reviewed draft-ietf-i2rs-pub-sub-requirements-06. Do I miss anything? - Editorial PENDING: The request has been receieved and queued for processing. s/receieved/received - Below is Menachem's question, part of his OPS-DIR review: As section 5.2 is labeled "I2RS Trace Log Mandatory Fields", I am wondering whether it is allowed to have additional optional fields. For example an optional "Additional Text" field may be useful, to provide additional information in certain situations.
Given that this is a framework document, rather than repeatedly declaring various operational aspects "out of scope" (7 times in 12 pages by my count), I would suggest just stating the requirements and guidance that are in scope. Readers should not be expecting to find lots of implementation details in this document. This would provide more clarity than saying that details are out of scope, but then specifying some of them anyway (e.g., for log trace rotation in 7.3). I agree with Stephen's DISCUSS and COMMENT.
draft-ietf-grow-route-leak-problem-definition
Thank you for an exceptionally well formed and well written coverage of route leaks.
Thanks for this well written document as others noted. I prefer a rewording of a somewhat choppy sentence in section 3.2 as it inaccurately quotes from the reference. The sentence says "[Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other." But the reference says "Example: UUNet (701) does not buy from Sprint (1239) to get to Globalcrossing (3549)." As this section in the document is "Example incidents" for Type 2, it infers this was an actual incident. But the reference itself simply says it is monitoring for this association. Suggest to reword: [Mauch] observes that its detection algorithm detects for these anomalies and potentially route leaks because very large ISPs do not in general buy transit services from each other.
- Thanks for doing this. The set of references alone seems particularly valuable. - section 2, does "propagation" in the definition mean that purely faked announcement messages (ignoring RPKI for the moment) that overlap with genuine announcements cannot be considered route-leaks? From the receiver POV, those would not be distinct. It was probably already suggested but if not, do you think would s/propagation/receipt/ or similar be a little better?
draft-holmberg-dispatch-pani-abnf
draft-alakuijala-brotli
Has there been an answer to the question in Paul Kyzivat's Gen-ART review about whether this draft is the authoritative specification?
Note for IESG: The reason why IESG is reviewing this document is because the IANA registration requires IETF Consensus RFC. Thank you for addressing my DISCUSS points.
Agree with Stephen's point about the IPR declaration.
Thank you for writing this specification. I am looking forward to recommending its approval soon. However, before doing so I would like to understand what the answer is to Paul Kyzivat's question regarding being an authoritative specification: It is unclear to me whether this document seeks to be an authoritative specification of the Brotli format, or simply an explanation of the format the supplements another specification. Do the authors have an answer?
Two valid questions asked by Dan Romascanu in his OPS DIR review: I believe the document is 'Almost Ready' for publication. I am no expert in compression, but my impression is that the document is clear and precise in defining the algorithm and the flow of operations on compression or decompression. From an operational point of view I have however two reservations: - There is no justification of any kind (mathematical proof, measurement results, etc.) that supports the claims that the performance resulting from the application of the algorithms results in ‘with an efficiency comparable to the best currently available general-purpose compression methods’. Even so, if the resulting performance is only ‘comparable’ with existing methods, why define a new one and publish it in an RFC? - There is no information or recommendations about the applicability of this format (what type of platforms, or network protocols) or documented results of its deployment – when should a software developer use it? Where should a network operator or IT manager apply it or activate it if available?
I agree with Stephen's comment requesting more references in the security considerations section to help readers/implementers.
- The IPR declaration confused me a bit. Do we know if it is saying that any implementation of the RFC for any purpose is RF or if it only means that RF applies to W3C stuff? (What's confusing is the last bit where it says the company "provides a W3C RF commitment" which is just a bit of an odd thing to see in an IETF IPR declaration.) Note: I think this is ok, as-is, but it's not entirely clear to me. If the folks who made the IPR declaration wanted to clarify that might be good, but I don't think it's absolutely needed. - The security considerations could do with some more references, at least one to a zip bomb and one to the crime attack. I think those would help some readers/implementers get the issues better. - I think it'd have been good to add a section on when the authors think it's a good and bad idea to use this algorithm. For example, would it make sense to ever use this for arbitrary (but not random) binary data? I don't mean a full analysis, but just some basic guidance. Not a big deal, but including that might avoid some repetition later on, esp if there are places where we know now that one ought not use this. - I agree with Alexey's discuss point #1.
dan romascanu performed the opsdir review.
conflict-review-irtf-icnrg-videostreaming