IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-08-04. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: John
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
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:
1033 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
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1043 EDT entered Executive Session
(at 2016-08-04 06:02:32 PDT)
draft-ietf-6man-multi-homed-host
In section 2.2, the document says: "The direct implication of Section 2.1 is that, if the network uses a routing protocol, the routing protocols used in multihomed networks SHOULD implement source-prefix based egress routing, for example as described in [I-D.ietf-rtgwg-dst-src-routing]." I understand the desire behind this statement - but find the SHOULD extremely strong given that we don't even have any routing protocol extensions adopted by ISIS, OPSF or even Babel WGs to handle source-prefix based egress routing. I know that we are actively discussing the problems motivating this statement and, I hope, making progress. However, I don't think that the dynamics or scaling or potential looping (for routers that don't support the same source prefixes) have been fully described or resolved. While this problem has been discussed in rtgwg, I do not yet see consensus in the Routing Area that this is the agreed solution. The email sent by v6ops about this problem recommended src-dest-routing as a solution and, indeed, that is being investigated. At a minimum, the language in this section needs to change from SHOULD.
general: I think this is very verbose, an editing pass to remove as many words as possible would be good, some examples below where I think more words confused me more than was needed... - Abstract: is bcp38 really crucial here or advisory? If the latter, then I'd suggest not making it sound like it is necessary, no matter how much we'd like it deployed. - intro: "the only consistent solution" may be an overstatement (unless you can prove there is no other) - text on p4 after figure 1: it's probably me but I found reading this a slog, not sure if it's really needed, but if (part of) it is, making the necessary bits clearer would seem like a fine plan. If it's not needed, maybe delete some or all of it. - 2.1: When you say SLAAC here, are you encompassing use of privacy addresses? Sometimes those are presented as an alternative to SLAAC but I'm not sure which is the more correct terminology. In any case, I assume this document is intended to fully work with privacy addresses.
I have a few minor comments: -1.1, indented paragraphs (A) and (B): It's not entirely clear to me if these restate requirements from 1122, or if these are requirements from this document that might "confuse" the Strong Host model. If the former, please consider dropping the 2119 keywords. -2.1, first paragraph: Please expand SLAAC on first mention. - 2.1, 2nd paragraph: s/implementation/implementations s/the two routers may not even know/each router may not even know -3, title: Does this refer to expectations the host has, or that other things have of the host? If the latter, what expects them? (Previous section talked about expectations the host has on the network; is this section about expectations the network (operator) has on the host?
Besides my first comment (which matches Alia's DISCUSS, which I support, but offers a slightly different point of view), I don't think that my comments raise to the point of a DISCUSS, but I would really like them to be considered as a STRONG COMMENT (stronger ones are at the top). 1. First of all, there's the topic of the scope. From Section 1. (Introduction and Applicability): "…the mechanics of egress routing once the packet leaves the host are out of scope." But then in Section 2.2. (Expectations of multi homed networks) you write that "The direct implication of Section 2.1 is that, if the network uses a routing protocol, the routing protocols used in multihomed networks SHOULD implement source-prefix based egress routing". I think that the "SHOULD" goes against the fact that routing is out of scope. While the general statement (of needing src-dst routing) may be true, for the networks shown in 2.1 all you really need is a default route as the topology and the host itself take care of selecting the correct exit point — so it is also not that direct of an implication. Proposed solution: ideally get rid of 2.2, but I'm fine with changing the "SHOULD" for something not in RFC2119, for example may need to/is for future investigation/… 2. In Section 1. (Introduction and Applicability) there are 2 places that say that implementations "will need to extend/add support". What does that mean? This document is a specification of what has to be done, so it shouldn't read like a list of future actions. Given that the next sentence warns that "Hosts that do not support these features may fail to communicate in the presence of filters as described above."…I would like to see the text be a little more prescriptive than just saying "will need to extend" or "will need to add support". "SHOULD" seems appropriate. 2.1. In the same piece of text… "…this specification is consistent with [RFC4861]. Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 4861 will need to extend their implementations accordingly." It would be very nice if the text included the sections where the appropriate extensions are mentioned/defined — presumably these extensions are how RFC4861 is Updated. 2.2. Same text… "This specification is fully consistent with [RFC6724] and implementers will need to add support for its Rule 5.5." It may not be apparent (at this point in the text) to everyone that 5.5 applies to the case where information related to which next-hop advertised which prefix (or that the document is going in that direction) -- please include a reference to section 3.3. 3. In Section 3.1. (Interpreting Router Advertisements), "…Bob-A and one had advertised itself as a default router or as having a route to Alice, that is the router Bob should choose. If none of Bob-A have advertised that but Bob-B has, it is irrelevant; Bob is using the address allocated in PA and courts a BCP 38 discard if he doesn't send the packet to Bob-A." I think this case is irrelevant too, but not because Bob knows/thinks about BCP 38 — it is irrelevant because of Rule 5.5 in rfc6724 (if I'm reading the order of the rules correctly). Please clarify.
draft-ietf-xrblock-independent-burst-gap-discard
I have a few minor comments: -1.1, 3rd paragraph, first sentence: Is the "MUST" a new normative requirement, or a statement of fact concerning 7003? If the later, please consider restating without the 2119 keyword. - 2, last paragraph: "RECOMMENDS" also seems like a statement of fact. Please expand "GMin" on first use. -3.2, definition of "I": Why define "I=01" then forbid it's use? -5, last sentence: Is the "MAY" a statement of fact?
Sorry still not an RT(C)P expert, but one question out of curiosity: Would it be a valid operation if I send one MIR Block per burst (by adapting the measurement duration dynamically), in case I really want to know the length of each burst separately? If so (or also if not, I guess), would it make sense to give recommendations about how often one should send feedback, or is this generally covered elsewhere (provide pointer!) that applies for this case?
p3, 1st sentence: "it" (used twice) is ambiguous
Liushucheng (Will) <liushucheng@huawei.com> provided the opsdir review. I think the discussion has been resolved to my satisfaction.
draft-ietf-mmusic-mux-exclusive
Quick question:
My initial understanding was that newer systems usually support RTP/RTCP
multiplexing, while older systems that do not support RTP/RTCP multiplexing
will also not be able to understand this new attribut. So I guess that's not
the use case. That means the use case if for newer system that do know about
RTP/RTCP multiplexing as well as the 'rtcp-mux-only' attribute but don't
support it for some reason. What are these reasons? Maybe you can provide some
more background about the intended usage here!
Minor:
Some sentences are a little hard to pharse as they are quite long, e.g.
OLD:
"When an offerer sends the initial offer, if the offerer wants to
indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
offerer MUST associate an SDP 'rtcp-mux-only' attribute with the
associated SDP media description ("m=" line)."
MAYBE:
"If the offerer wants to
indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
offerer MUST send the initial offer with an associated SDP 'rtcp-mux-only'
attribute and the associated SDP media description ("m=" line)."
In Section 3:
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp-
mux-only' attribute is 'IDENTICAL', which means that the attribute,
if used within a BUNDLE group
[I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all
multiplexed RTP-based media descriptions within the BUNDLE group.
This sounds pretty normative, so I think the following 2 references should be
Normative:
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-31 (work in progress), June 2016.
Tim Wicinski <tjw.ietf@gmail.com> performed the opsdir review.
draft-ietf-rtcweb-transports
Thanks for writing this. It's a well written document that really helps bring together the rather fragmented specifications that an implementor needs to understand. I have one minor and a few editorial comments: Minor Comments: - 4.2, 2nd to last paragraph:"Sending data over multiple 5-tuples is not supported." I am confused by this, since the last few paragraphs required support for a separate 5-tuple per media stream. That seems to be a form of sending data over multiple 5-tuples. Does this mean to distinguish "data" from "media", maybe in the in the sense of "data-channels"? - Informative References: Please consider whether the references to rtcweb-overview, RFC 4595, and RFC 7656 should be normative references. They are cited for definition of terms used in this document; if those definitions are needed to fully understand this document, they should be normative. (IMHO, these are borderline). Editorial Comments: - Please expand TURN, SSL, and ICE on first mention. - 3.4, 5th paragraph from end: "using TCP only between the endpoint and its relay" I _think_ this means the use of TCP on the hop between the endpoint and the relay and not on other hops, but some may read it as the use of TCP but not other protocols on that hop. - 4.2: There are a few instances of text of the form of "... packets...use a single DSCP code point", which I think would be more clear with s/a single/the same.
Thanks, I think this is a very useful and well written document. Sorry for my late discuss but I don't think this is anything complicated to address. Based on the TSV review I agree that this document should say more about congestion control. While the TSV reviewer (Thanks Allison!) only proposes to refer draft-ietf-avtcore-rtp-circuit-breakers-17 and draft-ietf-rmcat-cc-requirements-09, I would even prefer to have a normative sentence that says that congestion control MUST be implemented for all traffic flows. Please also provide the update on DSCP black-holing (in the middle of a flow) as mentioned by David Black.
Thanks for addressing the issues from my DISCUSS in version 15. I am clearing.
I noted that some comments that I agreed with have appeared during Last Call,
and hope they'll be reflected in a -15. Beyond that, I had a few comments of my
own, but wanted to thank the working group for producing very clear and helpful
transport guidance.
In this text
If some of the temporary IPv6 addresses, but not all, are marked
deprecated, the client SHOULD discard the deprecated addresses.
I would find some explanation of why this is a SHOULD to be helpful ("if some
of the addresses are deprecated, and you could discard them because you still
have addresses that are not marked deprecated, why would you not discard the
deprecated addresses?").
In this text
In order to deal with firewalls that block all UDP traffic, the mode
of TURN that uses TCP between the client and the server MUST be
supported, and the mode of TURN that uses TLS over TCP between the
client and the server MUST be supported. See [RFC5766] section 2.1
for details.
I think MUST for both TCP and TLS over TCP is still a good requirement, but I
note that RFC 5766 significantly predates RFC 7258, and wonder if it's worth
mentioning the tradeoffs in selecting which to use in a pervasively monitored
Internet, with RFC 7258 as a reference (RFC 5766 couldn't do that, of course).
In this text
For data transport over the WebRTC data channel
[I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support
SCTP over DTLS over ICE. This encapsulation is specified in
[I-D.ietf-tsvwg-sctp-dtls-encaps].
I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTLS over
ICE/UDP". That would be clearer to me.
I agree with
There exist a number of schemes for achieving quality of service that
do not depend solely on DSCP code points. Some of these schemes
depend on classifying the traffic into flows based on 5-tuple (source
address, source port, protocol, destination address, destination
port) or 6-tuple (5-tuple + DSCP code point). Under differing
conditions, it may therefore make sense for a sending application to
choose any of the configurations:
and the text that follows it, but I'm not understanding how a sending
application would know which configuration to choose, if we're still talking
about downloaded Javascript on an arbitrary browser instance (is that still
accurate? If not, my apologies).
Is the sending application just guessing/applying heuristics, or is there any
guidance (or a reference to guidance) you can provide?
I had the dame question as Stephen on why SSL instead of TLS, so thanks for clearing that up in the next revision.
I am glad this work is being completed.
draft-pd-dispatch-msrp-websocket
Thanks for making TLS a MUST-use in section 10. However, that makes me wonder why it's ever ok to not use TLS on the other side of the MSRP relay. I assume that's down to deployments that can't ensure TLS on both sides but that then raises some questions for me that I didn't see answered in the document, so I'd like to briefly check/chat-about those... (and also to ask if you can up the ante as well:-) (1) When both sides of the MSRP relay do want TLS, but the MSRP-relay-as-TLS-client fails to setup the "righthand" (referring to the draft's diagrams) TLS session, say because of a bad cert, what does the browser see? (That may be entirely obvious to someone who knows MSRP and need no change in the draft, but it wasn't clear to me.) (2) If the "righthand" MSRP session is not protected with TLS, then is that fully under the control of the client/browser? IOW, how does the browser/client express a desire that it really really wants TLS on both sides or else to fail? I think that's down to using msrps URIs but am not sure. Again that might be clear to anyone who knows MSRP but I don't:-) Can you clarify? (3) The answer is probably "no" but would it be feasible to say that a client for this MUST only use msrps: URIs? If it were feasible, that'd be good I think. If it's not feaasible, that's a pity, but I'm not asking that you add pretend statements about security we won't get;-)
- I also agree with Alissa's comment about the m= line and am glad to see that change was accepted. - 5.3.1: Why is there no option for TLS client auth here? If you allow cookies, then I don't see why you say nothing about that. - section 7: I don't get why you want/need CORS here - can you explain? (Not sure if something needs stating in the document, but as-is, it's unclear to me.) - 8.1.2 and elsewhere: It'd have been fine to only say once that MRSP doesn't allow line folding:-) - section 9: Thanks! Great to see that. - section 10: Thanks for saying that TLS MUST be used between client/browser and MSRP relay. That's a bit buried down here though - I think it'd have been good to say that at the top of the document too. (I got the wrong initial impression that you were allowing cleartext between the client/browser and MSRP relay from the start of the document.) - section 10: Do you need to add a security consideration saying that the MSRP relay can see the plaintext and that the client/browser shouldn't indicate e2e security to the user? - section 10: Wouldn't it be a good idea to add a statement that TLS as used here ought follow BCP195? (RFC7525)
In Section 10, last para: Any security considerations specific to the WebSocket protocol are detailed in the relevant specifications ([RFC6455] and [RFC4975]) and are considered outside the scope of this document. The certificate name matching and cryptosuite selection will be handled by the browser, and the browser's procedures will supercede those specified in [RFC4975]. Certificate name matching is described by RFC 6455, so the above text is not accurate. (The point about certificate matching from [RFC4975] not being used is correct though.)
I see in 5.2.2 that it is acceptable for clients to specify "TCP/MSRP" in an SDP m-line. But then in Section 10 there is the requirement for MSRP-over-websocket traffic to be protected by TLS, and RFC 4976 requires the same for all client-relay communications. What is the use case where a client would signal TCP/MSRP in an m-line while also indicating use of a websocket relay? I'm having trouble understanding why the option to specify TCP/MSRP is needed.
I see you've addressed Alissa & Mirja's comments, thanks for that. I also agree with Alexey's, but can't find the discussion, so I am not sure mail went out on it.
I agree with Alissa and Mirja on TCP/MSRP.
Nits/minor questions: 1) Please spell out MSRP at the first occurance in the 2. paragraph in the intro and give a reference s/MSRP/MSRP (Message Session Relay Protocol) [RFC4975]/ 2) In section 4.2 the following sentence is not fully clear to me: "The content of text frames MUST be interpreted as binary by WebSocket Clients and Servers." Wouldn't that break if the content of the text frame is actually UTF-8? Wouldn't it be better to ignor text frames? 3) Section 8.2.3 has a copy/paste error: Last transaction should be "F4 200 OK Alice -> a.example.com (transport WSS)" (and not " F4 200 OK Bob -> a.example.com (transport TLS)") 4) Inline with Alissa's comment: These two statement seem to contradict each other: "it is acceptable for an MSRP WebSocket Client to specify the "TCP/MSRP" or "TCP/TLS/MSRP" protocols in the SDP m-line" (section 5.2.2) and "MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP)." (section 10)
Fred Baker <fred@cisco.com> performed the opsdir review.
draft-sweet-rfc2910bis
I have a couple of items I would like to discuss before this progresses. I think these should be reasonably easy to resolve: - 8.1.1: The first paragraph requires support for MD5 and MD5-sess, and has no discussion of other algorithms. But the reference has been updated to RFC 7616, which is not quite compatible with that guidance. 7616 deprecates MD5, but allows it for backwards compatibility. It also makes SHA2-256 MTI. I realize there may be backwards compatibility issues, but I think the text should at least discuss the issue and encourage people to move away from md5. -9 If I read this section correctly, it requires (at SHOULD level) IPP/1.1 implementations to understand and correctly respond to IPP/2.X messages. How is this different from saying they SHOULD implement 2.X, but be backwards compatible with 1.1? ( I think this also applies to 2911bis).
Substantive Comments: -5, numbered list item 2: I’m confused—doesn’t this talk about creating a new HTTP/HTTPS URL from the IPP URL? How could this new URL already have an explicit port if you don’t put one in as part of that creation? Does this mean to add an explicit port to the HTTP URL if the IPP URL had one? -6: The media type has already been registered, hasn’t it? If so, it would be helpful to say that. I think a bis draft that obsoletes it’s predecessor does need to fully document anything registered by that predecessor, but also make it clear that it is not requesting a new registration. (It should describe any changes, though.) Should the security considerations field in the media type registration refer to the security considerations in this document? That section seems to invalidate the idea that IPP adds no security considerations over those of underlying transport protocols. -8: I'm surprised not to see a mention of integrity protection in this paragraph. -8.2.1: "IPP Clients and Printers MAY support Basic Authentication [RFC7617] for User Authentication if the channel is secure, e.g., IPP over HTTPS [RFC7472]." Is the intent to say you MUST NOT support Basic unless the channel is secure? if so, that's subtly different, since the current wording allows it for secure channels, but leaves the reader to infer that it is not allowed with insecure channels. (Also we are talking about "using" basic, not just "supporting" basic, aren't we? Editorial Comments an Nits: General: There's a fair amount redundancy with 2119 keywords (MUST, SHOULD, etc.). Much of that may be from the original text, but please try to avoid it when you can. When you have multiple bits of text that appear authoritative for the same requirement, it makes future updates more error prone. (I will call out a few specific instances, but probably missed a number of them.) Abstract: Please mention the obsoleted drafts in the abstract. (I know the draft shepherd disagrees with me on that point, but I think that it's useful information for people who read the abstract, sometimes in isolation from the full document, to see if they need to read the rest of the doc.) -4, first paragraph: Redundant with section 1, which provided quite a bit more detail. - 4.1, 3rd paragraph: Please avoid 2119 keywords in examples. (This is also redundant to the 2119 keywords in the following list.) -9.1, numbered list item 1: "SHOULD try supplying alternate version numbers" Should that say "SHOULD try supplying lower version numbers"?
One comment/question: I got stuck a little with the following sentences: "HTTP/1.1 [RFC7230] is the REQUIRED transport layer for this protocol. HTTP/2 [RFC7540] is an OPTIONAL transport layer for this protocol." I know the first one was there already in the RFC, but I'm just wondering if it is intentional to not say anything about the transport protocol underneath HTTP or not. Because RFC7230 is specified for the use with TCP but does not prohibit the usage of other transport protocol (given we would have another one that could fulfill the needed requirements). Should this doc explicitly say that HTTP1.1 over TCP or TLS/TCP, or is this not important?
- Review based on diff from RFC 2910 [1] - I see and like the reference to RFC7525, thanks. However that generates a question about the response to Kathleen's discuss: following RFC7525/BCP195 is the fine and correct thing to do, but that strongly deprecates TLS1.0 because as the BCP says "TLS 1.0 (published in 1999) does not support many modern, strong cipher suites." Doesn't that mean that if I follow the SHOULD and hence the BCP then I will not get interop with a (shockingly!) unmodified RFC 2910 implementation? And if that is true, then I don't see what still calls for you to not make at least implementing what BCP195 calls for a MUST. That shockingly non updated 16 year old stuff will presumably never be updated so it doesn't really matter that it doesn't adhere to this new document. (A similar point could be made about Ben's discuss point on MD5.) IOW, I think you can be much more aggressive in adding new MUSTs - all you need to do is to note the places where you do need to continue to interop with old and crappily updated things. (Which I'm sure do exist in the print world.) - I didn't see any text here along the lines of "and we changed this based on operational experience." That seems like a missed opportunity - aren't there a bunch of lessons learned from 16 years of implementation and deployment some of which'd be worth documenting here? (Apologies if I missed such text, or if its mostly in the 2911bis draft.) [1] https://tools.ietf.org/rfcdiff?url1=rfc2910&url2=draft-sweet-rfc2910bis-08.txt
Stephen has already raised on issue about MD5, but I wanted to copy here Matt
Miller's Gen-ART review, which also raised the same issue and a smaller
editorial issues.
I agree with Matt and Stephen that the document should have more explanation on
the MD5 issue, although, of course, for an old protocol you may not be able to
change. But at least the issue should be better described.
---
Almost ready. My one major issue is with the digest authentication
requirements, and really needs to be addressed in a way that
accounts for current security best practices.
I admit that I did not read the RFCs this document obsoletes.
I did not validate the correctness of any of the examples in
Appendix A.
Major issues:
* In Section 8.1.1. "Digest Authentication", support for MD5 and
MD5-sess is a MUST, which contradicts the NOT RECOMMENDED in
RFC 7616. I this is likely because of the giant number of existing
implementations, but it's a bad idea to continue the practice given
how compromised MD5-based schemes are. Maybe the following helps
find something acceptable?
IPP Clients and Printers SHOULD support Digest Authentication
[RFC7616]. For compatibility with existing implementations,
Clients and Printers SHOULD implement and support MD5 and MD5-sess.
However, MD5 and MD5-sess are NOT RECOMMNEDED for newer
implementations. Use of the Message Integrity feature
(qop="auth-int") is OPTIONAL.
Minor issues:
* The "meta-data" states this document obsoletes 2910 and 3382,
but the Abstract does not explicitly say this. There is the
editor's note, but it is helpful to put at least a mention in
the Abstract.
* In Section 3.2. "Syntax of Encoding", the ABNF in Figure 10 does
not parse in the tools I tried, because of the duplicate
reference. The following seems to me to accomplish the intent
while still parsing:
delimiter-tag = begin-attribute-group-tag / ; see section 3.5.1
end-of-attributes-tag /
future-delimiter-tag
future-delimiter-tag = %x06-0F ; see section 3.5.1
begin-attribute-group-tag = %x00 / operation-attributes-tag /
job-attributes-tag / printer-attributes-tag /
unsupported-attributes-tag / %x06-0F
operation-attributes-tag = %x01 ; tag of 1
job-attributes-tag = %x02 ; tag of 2
printer-attributes-tag = %x04 ; tag of 4
unsupported-attributes-tag = %x05 ; tag of 5
* Section 3.3. "Attribute-group", the last row in Table 1 indicates
the document content is "in a special position as described above",
which appears to be Section 3.1.1. It seems better to be more
explicit and say "in a special position as described in Section
3.1.1".
Nits/editorial comments:
* idnits complains that this document is attempting to reference
"rfc2910bis" (this document) without declaring the reference.
These are all in the IANA Considerations, so it seems enough to
me to change them to "this document".
Non-nits comments:
* idnits is complaining about "weird spacing" in a number of places,
but they are clearly part of a table (which is the sole content of
the containing section/appendix), and I think can be safely
ignored.
* idnits is complaining about a downref to RFC2818, but it's
already on the Downref Registry.
Thanks for your work updating this draft. I'd like to discuss the TLS recommendations to either see if we can change them or to improve the text and warnings around why TLS is recommended. Section 8.1.1 #2 I'm not sure why this is a reason why TLS is just a SHOULD. This seems to be a reason for it being a MUST. Is this just a text formatting issue? Should #2 be under a different heading? Sections 8.1.1 & 8.1.2: Preference: Could the text be re-written to have TLS as a MUST unless restrictions of the device make it so it is not possible or feasible? Not having TLS for authentication at least is a really bad idea. If it is just a SHOULD, when it is possible, developers may opt to not use TLS when there is no reason. If TLS stays as a SHOULD, I'd like to see stronger language around why it is recommended for use as the security considerations section only really talks about why it is not a MUST. It would be good to have sufficient motivation for developers and implementers to do the right thing.
Nit: It's not still new, is it? Abstract: This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP).
In 3.5.2 is "reserved for 'default' for definition in a future standards track document" really what you meant to say here? Does this mean 'default' is going to be defined in a future standards track document?
Mahesh Jethanandani <mjethanandani@gmail.com> performed the opsdir review
draft-sweet-rfc2911bis
- Review based on diff [1] from RFC 2911. Which is still gigantic:-( - It may be too late but I wondered why you had not considered opportunistic security for IPP - it seems to me like it'd be a really nice match for this protocol to get to where a bunch of stuff is encrypted when it can be. Please consider applying the principles from RFC 7435 and the opportunistic security for HTTP [2] draft here. It'd not be hard to specify this, and fairly easy to implement too and it'd be a fine improvement for little cost. [1] https://tools.ietf.org/rfcdiff?url1=rfc2911&url2=draft-sweet-rfc2911bis-09.txt [2] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-06
I need to re-LC the document, calling out DownRefs to the following documents:
** Downref: Normative reference to an Informational RFC: RFC 1951
Already in the DownRef registry.
** Downref: Normative reference to an Informational RFC: RFC 1952
GZIP
** Downref: Normative reference to an Informational RFC: RFC 1977
PPP BSD Compression Protocol
** Downref: Normative reference to an Informational RFC: RFC 2818
Already in the DownRef registry
** Downref: Normative reference to an Informational RFC: RFC 3196
Internet Printing Protocol/1.1: Implementor's Guide
** Downref: Normative reference to an Informational RFC: RFC 7612
Lightweight Directory Access Protocol (LDAP): Schema for Printer Services
-- Obsolete informational reference (is this intentional?): RFC 2565
(Obsoleted by RFC 2910)
-- Obsolete informational reference (is this intentional?): RFC 2566
(Obsoleted by RFC 2911)
These 2 Experimental RFCs are intended references.
---
** Downref: Normative reference to an Informational RFC: RFC 3239
Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device
Administrative Operations
This can be Informative
** Downref: Normative reference to an Informational RFC: RFC 3997
Internet Printing Protocol (IPP): Requirements for IPP Notifications
This can be Informative
I think this should be easy to resolve, but I would like to see discussion before the document progresses. This is closely related to my second discuss point for 2910bis: Section 4.1.8 says "IPP implementations SHOULD accept any request with the major version ’1’ or ’2’, or reject the request if the operation is not supported." The SHOULD level requirement for "forward" compatibility seems unusual. How is that different than saying implementations SHOULD implement 2.X and be backwards compatible to 1.1? If it's the same thing, then should have text discouraging new implementations of 1.1?
Substantive Comments: General : IDNits points out several normative downrefs, most of which are not in the downref registry. Some are from 2911, but some are new references. -3.4, "If a Client were to submit a Job using the secure URI, the Printer might assign the new Job a secure URI as well." Only "might"? Would it ever make sense to downgrade the URI security for the printer-assigned URI? - 4.1.6: "MAY include the RECOMMENDED ... attributes" MAY and RECOMMENDED are conflicting 2119 keywords for the same requirement. - 7: "Extensions registered for use with IPP/1.1 are OPTIONAL..." Given the existence of 2.X, do we really expect or want extensions to 1.1? - 7.1: Is "ipp@pwg.org" still the right place for designated experts? Experience has shown that "X-" or similar prefixes for protocol attributes is rarely helpful. The IETF has been deprecating that sort of thing in other places. Would it make sense to do so here for new extensions? -8, 11th paragraph: "...it is not related to the set of natural languages that MUST be accepted ..." The MUST is a statement of fact, not a 2119 keyword. Please don't capitalize it. (The caps were added since 2911.) -9, 1st paragraph: The small business example seems less believable today than it might have 16 years ago -- especially with potentially unsecured wireless networks. -- 4th paragraph: It seems like there should be some privacy considerations regarding client identities. -9.1.1, last paragraph: "Although the identity of the user can be trusted in this environment,..." Why would we assume that? It might be trusted, or it might not. Editorial Comments and Nits: - Abstract: Please mention the obsoleted RFCs in the abstract. - Editor's Note: Should this stay in the RFC? If not, a note to the RFC editor to that effect would be helpful. -2.3.11 "MUST support all REQUIRED attributes" is redundant. That's what "REQUIRED" means. - 4.1.5, 7th paragraph: "The operation target attributes are REQUIRED operation attributes that MUST be included in every operation request." REQUIRED and MUST are redundant 2119 keywords. (I think the MUST is more a statement of fact.) -6.1, paragraph 4: "MUST support all REQUIRED" is redundant.
Results of the discussion between Gen-ART reviewer (Russ) and author (Michael) should find their way into the draft.
Thanks for your work on this draft. I have some questions on the authentication text and would like to understand the reasons behind the current recommendations. Section 2.6.7 Can you add text to explain why authentication is a SHOULD? I see this says the recommendation is from the original document. Why isn't it being updated to be more secure, is that not possible (server auth only maybe?)? If I print anonymously, I'll want to know I am prating to the correct printer and that my print job is going off to multiple printers to steel my data, even at the library, etc. It would be helpful to know if there is a good reason. Is it just that this draft is just pulling together multiple existing RFCs and an update to this draft would take care of changes like increased security?
draft-ietf-dhc-topo-conf
Thanks for adding the enhanced security considerations text in -09 in response to the secdir review. [1] [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06603.html
draft-ietf-grow-blackholing
Firstly, thank you for documenting operational practice. With regards to section 3.3: "BGP speakers SHOULD only accept and honor BGP announcements carrying the BLACKHOLE community .." I really question why this is a "SHOULD" and not a "MUST", even in an informational RFC. Is the ability for a transit provider so loose that appropriate route filters from a peer ASN can't be applied so that only a "SHOULD" is practical? In which case I do question the sanity of making such a recommendation and thus service available if some other ASN might be able to inject the route and affect another service, even by mistake. Potentially if RPKI is in use, then a peer AS might be able to validate the announcement against a ROA. But it strikes me that this is not the machinery you would want to tack on in this case. The same could be said for section 3.2. I would be rather wary of NOT adding a NO_ADVERTISE (at the very least) and to be honest SHOULD still seems far too loose for me. Almost all of the recipe's that I've gazed upon
From a comment point of view, this informational document is agnostic on any operational differences between 2-byte and 4-byte ASNs. Is that intentional? Are there any operational differences worth calling out in regard to using extended communities etc?
Shepherd write-up says intended status is "Proposed Standard". I assmue Informational is correct though.
I think this is an important document...but I do have some non-blocking comments: 1. This document defines a community, not an attribute, so Section 2 (for example) should be renamed — there are a couple more places that also need updating. 2. In Section 3.1. (IP Prefix Announcements with BLACKHOLE Community Attached): "When a network is under DDoS duress, it MAY announce an IP prefix covering the victim's IP address(es)…In such a scenario, the network operator SHOULD attach BLACKHOLE BGP community." I think the "MAY" is not needed because this whole process is optional…and the qualification really comes in the next sentence. Why is the "SHOULD" not a "MUST"? In other words, if the sender decided to make an advertisement "for the purpose of signaling to neighboring networks that any traffic destined for these IP address(es) should be discarded", when would it not include the new community? 3. Section 3.2. (Local Scope of Blackholes) says that "Unintentional leaking of more specific IP prefixes to neighboring networks can have adverse effects. Extreme caution should be used when purposefully propagating IP prefixes tagged with the BLACKHOLE BGP community outside the local routing domain." However, no further examples or security-related considerations are mentioned about the first sentence. The Security Considerations section does talk about an attack resulting from inserting the BLACKHOLE community where it shouldn't be, but I would like to see some more on the effects of propagating a prefix that was correctly tagged (as mentioned in the second sentence). In summary, I think that the statements above are not without merit, but it would be helpful for others to better describe the potential effects. 4. I think that Section 4. (Vendor Implementation Recommendations) is superfluous. It talks about explicit configuration — the community is already defined as providing "advisory qualification" in Section 2. And then it suggests calling the community "blackhole"… 5. In Section 6. (Security Considerations)… 5.1. The correct reference for BGPSec is draft-ietf-sidr-bgpsec-protocol. 5.2. The RPKI reference (RFC6810 = The Resource Public Key Infrastructure (RPKI) to Router Protocol) seems out of place. I'm not sure if you really want to refer to Origin Validation (rfc6811) or something else (?). In any case, it is true that communities are not protected. 5.3. Section 3.3. (Accepting Blackholed IP Prefixes) says that "BGP speakers SHOULD only accept and honor BGP announcements…for which the neighboring network is authorized to advertise." That sounds like Origin Validation to me. Given that Section 3.2. (Local Scope of Blackholes) is not strict (uses "SHOULD" and not "MUST" when talking about propagation of marked routes outside the receiving AS), I would like to see a sentence or two about how Origin Validation can help determine if the neighbor is in fact authorized. [Non-normative.]
I'm balloting "no objection", but I share some of the discomfort around Stephen's discuss point 1, and will follow the conversation in the resulting thread. The "extreme caution" admonition in 3.2 could use elaboration. In the email thread related to Stephen's discuss, Jeff mentioned existing undocumented operational practices that mitigate the risk of accidental propagation; perhaps something along those lines could be mentioned here?
Thanks for writing this draft to document the practice.
First, I have to say that I'm pretty ignorant about practical routing operations, so my plan is to briefly discuss this and to then probably move to an abstain position, unless the issues I raise resonate with folks who are expert in this space. (1) I agree with the points raised in IETF LC that the transitive nature of this proposal has dangers that may outweigh its utility. Was there discussion in the WG about potential solutions that do not have the transitivity property? If so, can you point me at those? If not, is there a reason to think no such solution is feasible? (I suspect the answer may be "no" which is the main reason I plan to move to an abstain ballot.) (2) IIUC, this proposal envisages BGP speakers commonly telling others to blackhole specific /32's or /128's. And of course as the draft says BGP doesn't provide us with a way to "prevent the unauthorized modification of information by the forwarding agent." Given those two things, this scheme seems to be an ideal new way to cause any service that advertises a fallback to actually fall back, e.g to use a secondary MX or DNS resolver rather than a primary. That seems like a fine way to try and possibly succeed in attacking many possible things. The discuss point here is to ask if this really is a new attack vector, and if so, if the appropriate level of analysis of its impact has been done? If this is new, then I don't see that the security considerations text adequately describe the range of possible attacks that could be mounted using this scheme. (As an aside, I wonder if asking to blackhole /32's and /128's might impact on routing table sizes and if something ought be said about that?) (3) Given that there are dangers associated with this mechanism, why is there no statement in the draft that actions taken based on this scheme ought be logged or otherwise publicised as a possible way to provide some level of accountability, even if only after the fact?
- 3.2: It isn't clear to me how one might exercise "extreme caution" here - can you explain? Or is that obvious to the intended audience of this?
After reading the IETF LC thread on this, I am quite conflicted. I appreciate that defining this community will make things easier operationally, but I'm concerned that it will also make it easier to intentionally or unintentionally cutoff traffic to a destination that is not suffering a DDoS attack. I don't see the changes from the -00 to the -02 really helping much in that regard. The change from PS to informational is not terribly meaningful since the community is being registered either way and the removal of the bits about IXPs doesn't mitigate the risks either. If there was a way to authenticate the attribute I would feel differently, but my understanding is that that is not currently possible with BGP. This is far outside my area of expertise so I don't intend to try to block publication or offer anything in the way of an alternative, but I also don't feel comfortable supporting the publication of this document.
draft-ietf-6lo-ethertype-request
draft-holmberg-dispatch-rfc7315-updates
I guess the following sentence should be normative: OLD: The P-Access-Network-Info header field shall not be included in SIP ACK requests triggered by non-2xx responses. NEW: The P-Access-Network-Info header field SHALL NOT be included in SIP ACK requests triggered by non-2xx responses.
Ron Bonica rbonica@juniper.net performed the opsdir review
conflict-review-behringer-ncrg-complexity-framework