Re: [Gen-art] Gen-ART LC Review of draft-ietf-opsec-dhcpv6-shield-04
Hi, Ben, It looks like I never responded to this one. -- My apologies for that. Please find my comments in-line... On 12/11/2014 06:56 PM, Ben Campbell wrote: Minor issues: -- abstract, last sentence: I didn't find this assertion in the body itself. It would be nice to see support for it (perhaps with citations). I guess one could provide references to some vendor's manuals? Is that what you have in mind? (although I'd prefer not to do so). The citations part was more of a nice to have. But it would be worth putting some words around that in the body, even if there's nothing to reference. ANy suggestions on this one? -- section 4: Am I correct in understanding that this is opt in only? You would disallow a rule of the form of allow on any port except [list]? Not sure what you mean. The idea is that if you want to enable dhcpv6 shield, you need to specify on which port(s) the dhcpv6 server(s) is/are connected. Would a rule of the form Allow DHCPv6 on all ports except port X be allowed? Yes. That's another way of saying: Enable DHCPv6-Shield. Allow DHCPv6 on ports 1-7 -- when a device has ports 1-8. i.e., DHCPv6-Shield is, when enabled, a default deny -- and you need to specify on which port(s) DHCPv6 should be allowed. -- section 1, 3rd paragraph: It would be helpful to define what a DHCP-Shield device is, prior to talking about deploying and configuring them. How about adding (in Section 1) the following text: This document specifies DHCPv6 Shield: a set of filtering rules meant to mitigate attacks that employ DHCPv6-server packets. Throughout this document we refer to a device implementing the DHCPv6 Shield filtering rules as the DHCPv6 Shield device ? Yes, thanks. FWIW, we ended up adding all these definitions to the Terminology section. -- section 3, paragraph ending with with ... used as follows [RFC7112]: I'm a bit confused by the citation. Are these defined as follows, or in 7112? You did not respond to this one. I note that my next few comments might no longer apply if the 7112 reference is clarified. Is the point to say that 7112 contains the following definitions, which are repeated here for the sake of convenience? Yes, that's the point. And we've updated the text to say ..used as defined in [RFC7112]. Also, while this section talks about some aspects of header chains, it never actually defines the term. Which one? The term header chain. That is, something of the form of The IPv6 header chain is a linked-list of IPv6 headers. It contains We never use header chain alone, but rather IPv6 header chain. -- section 3, Upper-Layer Header Again, this section talks about the term without defining it. -- section 5, list entry 1: ... the IPv6 entire header chain ... Not sure what you mean: Section 3 is all about defining the terms. Am I missing something? Again, the definition doesn't actually define the term. For example, An upper-layer header is a header belonging to an upper-layer protocol mm.. but that wouldn't be correct. The current definition seems to be more correct than that. Not sure what is missing... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art last call review of draft-ietf-httpbis-http2-16
Thanks for the thorough review Elwyn. I've made changes in the form of a proposed change set against the editor's copy. https://github.com/http2/http2-spec/pull/692 You can review the changes at that link. Note that some of the typos you caught were already fixed, or will be fixed in other proposed change sets. As is customary, I will await a sanity check and AD/shepherd approval to merge the changes into the master copy. I expect that to occur after the IESG discuss approval. Responses inline. On 19 January 2015 at 02:37, Elwyn Davies elw...@dial.pipex.com wrote: Summary: Almost ready. A well written document with just a few nits really. I am slightly surprised (having not been following httpbis in detail) that HTTP/2 is so tightly wedded to TCP - this is doubtless pragmatic but it adds to the ossification of the Internet and makes me slightly suspicious that it is an attempt to really confirm HTTP/2 as the waist of the neo-Internet. Can't we ever use any other transport? I think that - overall - the desire for the timely replacement of HTTP/1.1 was stronger than the desire to attain perfection. And rather than ossifying, the general view is that ALPN clears a path to more changes in the future. If you want to talk about the waist of the neo-Internet, I think identifying HTTP more generally is appropriate; we're only really upgrading a small part of it. And there are ongoing plans to continue to upgrade the entire protocol. But our relevance is only defined by what we ship, and this is a significant improvement that isn't worth holding back for years while we ponder more fundamental changes. A couple of minor issues: (1) I am not sure that I see the (security) value of the padding mechanisms specified, but I am not an expert so I will defer to the security experts, and (2) the extension method for SETTINGS seems to be flawed. Apologies for the slightly delayed review. I'll address those below. And don't concern yourself with the delay, it's not a small document. Major Issues: s3, para 1: Just checking: HTTP/2 is defined to run over TCP connections only. I take it that this is something that the WG has formally decided upon. Is there something that stops HTTP/2 running over any other reliable byte stream protocol with in-order delivery? Could there be a more general statement? Such a statement was debated at some length. The current view (unless I'm mistaken) was to recognize that HTTP/2 uses TCP. More definitive statements were avoided to ensure that if a future document chose to define how HTTP/2 used some other transport that wouldn't be too disruptive. And who said it needed to have in-order delivery? Referring to the cited section, the accepted view on ALPN tokens is that they identify a particular application protocol profile; a new protocol that layered something that was partially or substantially like HTTP/2 over another transport would have a new identifier. Minor Issues: s4.3, next to last para; s5, bullet #1: (Just a bit more than a nit) s4.3 says: Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream. s5 says: o A single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams. If s4.3 is correct (which multiple repetitions elsewhere indicate that it is) then the bullet in s5 needs to reflect the constraint in s4.3 as they are currently inconsistent. Section 5 is summary information. I don't think that further qualification is needed at this point; as you note, the constraint is repeated frequently. I am not quite sure whether the last para of s4.3 implies that the client must wait until it has the whole header block before trying to decompress or whether decompression might happen as fragments are received - please clarify this in the text. That's a clarification that belongs in the header compression document. It appears in Section 3.1 of that document. s6.1 and s6.2: I am dubious about the value of the padding story in DATA and HEADERS frames, even given the caveats in s10.7. An attacker can use the header to deduce the padding section. It seems a bit odd to say that you can add arbitrary padding and then insist it is all zeroes. However, I am not an expert in this area and will defer to security experts. Hard as it is to get right, padding here is important in some use cases. We've had a lot of separate requests for the feature. The all zeros thing is safe if your cipher provides IND-CCA, and that is table-stakes. You are right though about the arbitrary thing, I've removed the word arbitrary. s6.5.3: If an endpoint sends a SETTINGS value that the receiving endpoint doesn't understand (for an extension, say), the receiver will ignore it but still send an ACK. This leaves the sending endpoint unaware that the other
Re: [Gen-art] Gen-art last call review of draft-ietf-httpbis-http2-16
Hi, On 1/20/15 8:17 AM, Martin Thomson wrote: On 19 January 2015 at 02:37, Elwyn Davies elw...@dial.pipex.com wrote: Summary: Almost ready. A well written document with just a few nits really. I am slightly surprised (having not been following httpbis in detail) that HTTP/2 is so tightly wedded to TCP - this is doubtless pragmatic but it adds to the ossification of the Internet and makes me slightly suspicious that it is an attempt to really confirm HTTP/2 as the waist of the neo-Internet. Can't we ever use any other transport? I think that - overall - the desire for the timely replacement of HTTP/1.1 was stronger than the desire to attain perfection. And rather than ossifying, the general view is that ALPN clears a path to more changes in the future. If you want to talk about the waist of the neo-Internet, I think identifying HTTP more generally is appropriate; we're only really upgrading a small part of it. And there are ongoing plans to continue to upgrade the entire protocol. But our relevance is only defined by what we ship, and this is a significant improvement that isn't worth holding back for years while we ponder more fundamental changes. THIS version of HTTP is very much focused on multiple streams of communication. There is the equivalent of source quench, prioritization, and windowing; and indeed the intent is to reduce the number of parallel TCP connections. This having been said, I don't see this point as against HTTP2, but a reflection of the difficulty in making substantial changes to the transport layer. The IAB have had one workshop that touched on this point (ITAT)[1] in which Elwyn participated, and next week we will hold another (SEMI)[2]. Eliot [1] http://tools.ietf.org/html/rfc7305 [2] https://www.iab.org/activities/workshops/semi/ signature.asc Description: OpenPGP digital signature ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review of draft-ietf-drinks-spp-protocol-over-soap-07
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-drinks-spp-protocol-over-soap-07 Reviewer: Roni Even Review Date:2015-1-17 IETF LC End Date: 2015-1-22 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: There are two schemas used, the sppf:base and sppf:soap each have a version number. When talking about supported version and about response codes on supported version, is it referring to the base or soap version? There is some text in the minorVer section but it is not clear enough. Nits/editorial comments: The complexType name=ResultCodeType is defined in multiple subsections (7.2.1.2 , 7.2.2.2 , .) but not in all places, should be specified only once or in all. Also the definitions in section 7 are not consistent with the ones in section 9 which is the formal definition. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Telechat Call review of draft-ietf-radext-radius-fragmentation-10
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-radext-radius-fragmentation-10 Reviewer: Meral Shirazipour Review Date: 2015-01-19 IETF LC End Date: 2014-12-25 IESG Telechat date: 2015-01-22 Summary: This draft is ready to be published as Experimental RFC. Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Telechat Call review of draft-ietf-json-i-json-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-json-i-json-05 Reviewer: Meral Shirazipour Review Date: 2015-01-19 IETF LC End Date: 2015-01-14 IESG Telechat date: 2015-01-22 Summary: This draft is ready to be published as Standards Track RFC but I had some comments [1] . [1] http://www.ietf.org/mail-archive/web/gen-art/current/msg11198.html. Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
