Nicolas Williams writes:
> On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
> > Yes. That was what I tried to say. Do you think my already changed
> > sentence is ok, or do we need to explain it more.
>
> Well, the heuristics will benefit from the information cached for the
> TCP/UDP
On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
> Nicolas Williams writes:
> > - Section 8.3, 1st paragraph, 2nd sentence: this sentence is
> >grammatically incorrect, and I'm unsure as to what is meant.
>
> This was commented already by others and was changed to:
>
> For e
Nicolas Williams writes:
> - Section 7, 1st paragraph: MOBIKE is mentioned without a reference.
> - Section 7, 2nd paragraph: s/avare/aware/
> - Section 8.1, next to last sentence: this sentence is grammatically
>incorrect, I think. How about:
> If the protocol (also known as the, "ne
Thanks, Nico! However...
At 1:35 PM -0500 10/13/09, Nicolas Williams wrote:
>Note: I did not review the appendix nor its sub-sections.
Please do. :-)
Seriously, folks, the appendix is pretty important, inasmuch as some developers
will pay more attention to it than they do the main body. It woul
On Tue, Oct 13, 2009 at 01:34:24PM -0500, Nicolas Williams wrote:
> Done.
One more comment:
- State keeping by intermediate nodes is described as an optimization,
however: a) I'm not sure that that necessarily follows, since state
keeping and cache index lookups are not free, and anyways,
Note: I did not review the appendix nor its sub-sections.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
- Section 7, 1st paragraph: MOBIKE is mentioned without a reference.
- Section 7, 2nd paragraph: s/avare/aware/
- Section 8.1, next to last sentence: this sentence is grammatically
incorrect, I think. How about:
If the protocol (also known as the, "next header") of thepacket is
Hi everyone,
To date we've had only two last call reviews of this document. Please consider
this a personal invitation to be the lucky third. We simply cannot advance the
document unless we're convinced it's had adequate review.
We are hereby extending the WGLC by another 2 weeks, until Oct. 27
I support advancing this document, and I think the explanations and
pseudo code are good.
I do, however, question the value of it in real life.
Security policies or the deep inspection kind usually are something
like:
- allow HTTP and HTTPS, and verify headers
- allow ICMP and DNS
- may
Scott C Moonen writes:
> - Is Section 1.2 necessary? None of these terms are used in this fashion
> in this document.
True. Removed.
> - page 8, "sees an new" => "sees a new"
> - page 8, "in the Section 8" => "in Section 8"
Fixed.
> - page 12, excessive space in "i.e. UDP encapsulated"; per
Here are my comments:
- Is Section 1.2 necessary? None of these terms are used in this fashion
in this document.
- page 8, "sees an new" => "sees a new"
- page 8, "in the Section 8" => "in Section 8"
- page 12, excessive space in "i.e. UDP encapsulated"; perhaps replace
with comma.
- page 16,
11 matches
Mail list logo
