Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Spencer Dawkins at IETF]

On Thu, Dec 6, 2018 at 7:18 AM Stewart Bryant 
wrote:

>
>
> On 06/12/2018 07:55, Dongjie (Jimmy) wrote:
> > Hi Spencer, Stewart, Joel,
> >
> > Thanks for the discussion about the congestion adaptation. We agree the
> reactive congestion adaptation may need further investigation.
> >
> > Thus in order to solve Mirja's comment, we plan to make that example
> more generic with something like:
> >
> > "For example, the collected information could be used for traffic
> monitoring, and could optionally be used for traffic optimization according
> to operator's policy."
>
> Sounds much better.
>

I defer to Mirja since this is her ballot, but that sounds much more sane
to me :-)

Thanks for considering my comment on Mirja's comment!

Spencer


> Stewart
>
> >
> > Best regards,
> > Jie
> >
> >> -Original Message-
> >> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> >> Sent: Wednesday, December 05, 2018 12:03 AM
> >> To: Spencer Dawkins at IETF ; Stewart
> >> Bryant 
> >> Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Mirja Kuehlewind
> >> ; IESG ;
> >> draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org
> >> Subject: Re: [OPSAWG] Mirja Kühlewind's No Objection on
> >> draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
> >>
> >> The conclusion earlier work on congestive response routing reached was
> that
> >> one needed to pin the specific routing decision until the selected path
> became
> >> infeasible.
> >>
> >> Yours,
> >> Joel
> >>
> >> On 12/4/18 10:59 AM, Spencer Dawkins at IETF wrote:
> >>> Hi, Stewart,
> >>>
> >>> On Tue, Dec 4, 2018 at 6:07 AM Stewart Bryant
> >>> mailto:stewart.bry...@gmail.com>> wrote:
> >>>
> >>>
> >>>
> >>>  On 30/11/2018 19:23, Spencer Dawkins at IETF wrote:
> >>>>  This is Mirja's comment, but ...
> >>>>
> >>>>  On Fri, Nov 30, 2018 at 10:12 AM Mirja Kühlewind
> >>>>  mailto:i...@kuehlewind.net>> wrote:
> >>>>
> >>>>  Mirja Kühlewind has entered the following ballot position for
> >>>>  draft-ietf-opsawg-ipfix-bgp-community-11: No Objection
> >>>>
> >>>>  When responding, please keep the subject line intact and
> reply
> >>>>  to all
> >>>>  email addresses included in the To and CC lines. (Feel free
> to
> >>>>  cut this
> >>>>  introductory paragraph, however.)
> >>>>
> >>>>
> >>>>  Please refer to
> >>>>  https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>>>  for more information about IESG DISCUSS and COMMENT
> >> positions.
> >>>>
> >>>>  The document, along with other ballot positions, can be found
> >>>>  here:
> >>>>
> >>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-communit
> >>>> y/
> >>>>
> >>>>
> >>>>
> >>>>
> --
> >>>>  COMMENT:
> >>>>
> >>>> -
> >>>> -
> >>>>
> >>>>  One comment on section 1:
> >>>>  "For example, they can shift some flows
> >>>>from congested links to low utilized links through an SDN
> >>>>  controller
> >>>> or PCE [RFC4655]."
> >>>>  I'm not aware that ipfix information is commonly used for
> >>>>  dynamic traffic
> >>>>  adaptation and I'm not sure that is recommendable. C
> >>>>
> >>>>
> >>>>  I'm agreeing with Mirja here.
> >>>>
> >>>>  We've spent a LOT of time not recommending dynamic traffic
> >>>>  adaptation. Probably half my responsibility as AD for ALTO was
> >>>>  repeating "you can't react based on changes to that attribute
> >>>>  without taking chances on oscillation" like it was a mystical
> >>>>  incantation, and I wasn't the first AD to have that conversation
> >>>>

Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Stewart,

On Tue, Dec 4, 2018 at 6:07 AM Stewart Bryant 
wrote:

>
>
> On 30/11/2018 19:23, Spencer Dawkins at IETF wrote:
>
> This is Mirja's comment, but ...
>
> On Fri, Nov 30, 2018 at 10:12 AM Mirja Kühlewind 
> wrote:
>
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-opsawg-ipfix-bgp-community-11: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> One comment on section 1:
>> "For example, they can shift some flows
>>   from congested links to low utilized links through an SDN controller
>>or PCE [RFC4655]."
>> I'm not aware that ipfix information is commonly used for dynamic traffic
>> adaptation and I'm not sure that is recommendable. C
>
>
> I'm agreeing with Mirja here.
>
> We've spent a LOT of time not recommending dynamic traffic adaptation.
> Probably half my responsibility as AD for ALTO was repeating "you can't
> react based on changes to that attribute without taking chances on
> oscillation" like it was a mystical incantation, and I wasn't the first AD
> to have that conversation repeatedly.
>
>
> Yes, I understand the ARPA net had exactly that problem at one stage and
> had to be converted from using a delay based metric to a fixed metric.
>
>
> I would be happy to hear that all those problems are solved, but I haven't
> heard that yet. Do the right thing, of course.
>
> Even "can shift some flows from persistently congested links to
> underutilized links" would cause me less heartburn.
>
>
> There is no such thing as permanent in network paths!
>
> Like many control problems the first order solution is to damp with a
> suitably long time constant, but  infinity, i.e. permanent, is not a
> satisfactory choice either.
>

Yeah, that's where I was headed (stated more coherently).

Saying "I should do something, because the network path is STILL congested"
is safer than "I should do something because the network path is
congested", so now we're talking about suitable definitions of "STILL". I
was shooting for that with "persistent", and agree that "permanent" path
characteristics is a happy idea we aren't likely to see in practice.

Do the right thing, of course ;-)

Spencer


> - Stewart
>
>
> Spencer
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Mirja Kühlewind's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Spencer Dawkins at IETF]

This is Mirja's comment, but ...

On Fri, Nov 30, 2018 at 10:12 AM Mirja Kühlewind 
wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-opsawg-ipfix-bgp-community-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/
>
>
>
> --
> COMMENT:
> --
>
> One comment on section 1:
> "For example, they can shift some flows
>   from congested links to low utilized links through an SDN controller
>or PCE [RFC4655]."
> I'm not aware that ipfix information is commonly used for dynamic traffic
> adaptation and I'm not sure that is recommendable. C


I'm agreeing with Mirja here.

We've spent a LOT of time not recommending dynamic traffic adaptation.
Probably half my responsibility as AD for ALTO was repeating "you can't
react based on changes to that attribute without taking chances on
oscillation" like it was a mystical incantation, and I wasn't the first AD
to have that conversation repeatedly.

I would be happy to hear that all those problems are solved, but I haven't
heard that yet. Do the right thing, of course.

Even "can shift some flows from persistently congested links to
underutilized links" would cause me less heartburn.

Spencer


> an you maybe choose a
> different example. E.g use of IPFIX for troubleshooting or more generally
> network monitoring? Thanks!
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Eliot,

On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  wrote:

> Responding to Spencer, Ben, and Alexy (in order).
>
> On 16.04.18 21:09, Spencer Dawkins wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found 
> here:https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> COMMENT:
> --
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a Yes.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I note 
> that
>
> 3.15.  direction-initiated
>
>When applied this matches packets when the flow was initiated in the
>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>practices.  While that document is scoped specifically to IPv6, its
>contents are applicable for IPv4 as well.  When this flag is set, and
>the system has no reason to believe a flow has been initiated it MUST
>drop the packet.  This node may be implemented in its simplest form
>by looking at naked SYN bits, but may also be implemented through
>more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through more
> stateful mechanisms" in 2018. Do the right thing, of course.
>
>
> I proposed a clarification: direction initiated is a TCP element.
>

That is a clarification.

I guess what I'm thinking, on reflection, is that direction is likely to be
helpful for TCP-based communication, is not likely to be helpful for
UDP-based communication without stateful inspection (so, my camera probably
does need to act as a DNS client, but probably doesn't need to act as a DNS
server), and is likely to be increasingly unhelpful if we really do see
things using encrypted, UDP-based transports like QUIC.

This does poke the "how are network managers going to manage networks
running encrypted, UDP-based transport" bear, but that's way bigger than
this document. Say as much as you think is helpful, and then move on, I
think.

> Does
>
> 3.5.  is-supported
>
>This boolean is an indication from the manufacturer to the network
>administrator as to whether or not the Thing is supported.  In this
>context a Thing is said to not be supported if the manufacturer
>intends never to issue an update to the Thing or never update the MUD
>file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"?
>
>
> Mostly that what it means, but the implication is that there's no support,
> and enterprise administrators in particular might want to know that
> (usually they do- because those devices represent a particular risk).
>

 Here, I must apologize, because I've been thinking of MUD as the other
side of a coin that also has SUIT, TEEP, and similar tools - If your Thing
is just being installed and forgotten until it's an attack platform, you
need MUD descriptions, but if your Thing is going to be updated, you should
be looking at SUIT, TEEP, and whatever else seems helpful.

I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
that's a lack of imagination on my part, but the most relevant side effect
of that, is that if you know what your printer needs to do, to be a network
printer, and you get a MUD description for it, and the printer isn't going
to be updated, that MUD description should be fine, forever.

I'm still connecting dots.

> "Supported" covers a lot of ground …
>
> If a manufacturer sells off one product line (so, flobbidy.example.com covered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
> maintained by a manufacturer that isn't flobbidy.example.com), is there a good
> plan for what comes next? I'm not sure what happens to is-supported, for
> instance.
>
>
> The intent is that the entity providing the MUD file (probably the
> manufacturer) will not be issuing software/firmware updates or MUD file
> updates.  But your point is more about device lifecycle, and that's a more
> interesting question than just "is-supported".  Steve Rich and Thorsten
> Dahm have begun to delve in that direction.  There are at least a few
> possibilities, such as the use of redirects, or even domain names that are
> used for particular classes of devices, or even common repos.  More work
> needed.

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

I haven't balloted yet, and this is EKR's ballot thread, but one point is
worth bringing up here ...

On Mon, Apr 16, 2018 at 7:25 AM, Eric Rescorla  wrote:

> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits into
> the system as a whole.
>
> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>
> - Additive -- it lets the device do things it otherwise might not be
> permitted to do (e.g., accept incoming TCP connections)
> - Restrictive -- it stops the device from doing things that it otherwise
> would be permitted to do (e.g., make connections to IP addresses on non-443
> ports)
>

I've read previous versions of this draft and some of the mailing list
discussion, but not a lot. Having said that, I hadn't heard anyone express
the possibility of the additive case described here. The context I always
heard about, was roughly "we've gotta keep all the coke machines on campus
from doing anything except reporting that they need to be refilled", or
whatever variation of cameras, printers, or *mumble* have access to your
network for a specific reason, are running some arbitrary version of some
OS stack that included TCP or UDP capabilities, aren't being maintained
enough to be current on security patches, and aren't being managed, so are
ripe for attacks to create botnets.

Perhaps I need to get out more. Almost certainly. But ... the possibility
of additive policies is interesting, and new to me.

I'll be interested to watch this discussion. Eric, thanks for asking the
question.

Spencer

In the former case, it's very important not to be able to forge acceptable
> MUD policies, but in the latter case, an attacker can just not serve *any*
> MUD policy and be in a stronger position than they would be if they had a
> valid policy, Thus, it's only in the former (additive) case where forging a
> policy is useful to the attacker, and, in fact, it seems like accepting an
> unsigned MUD policy would be better than no policy. Given the ubiquity of
> non-MUD devices and the relatively limited capabilities that MUD seems to
> want to convey, it seems like the additive case isn't very useful.
>
> I should mention one use case that I did think of, where additive would be
> immediately useful: "This device is made by the same manufacturer as
> another device (and hence they can talk to each other). However, I note
> that MUD is actually not capable of securely conveying that, because
> there's no proof that the device in hand actually is made by the
> manufacturer, only that it possesses a public credential for some device
> made by that manufacturer. So, I'm actually left wondering how that feature
> is intended to work. I regret not catching this earlier, but perhaps you
> could explain?
>
> Thanks,
> -Ekr
>
>
> On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear  wrote:
>
>> Hi Eric,
>>
>> Trimming.
>>
>> On 15.04.18 21:22, Eric Rescorla wrote:
>>
>>
>>
>>
>>
>>> IMPORTANT
>>>
>>>  The certificate extension is described below.
>>>
>>>  The information returned by the MUD file server (a web server) is
>>>  valid for the duration of the Thing's connection, or as specified in
>>>  the description.  Thus if the Thing is disconnected, any associated
>>>  configuration in the switch can be removed.  Similarly, from time to
>>>
>>> IMPORTANT: What does "disconnected" mean in this context? Does a
>>> reboot count? What if I am wireless? This is a critical question if
>>> MUD is intended as a post-compromise mechanism. Say that an attacker
>>> compromises the firmware for a device and then forces a reboot
>>> followed by a 2 hour pause before the wireless NIC is activated. Will
>>> this result in configuration removal? If so, MUD seems of limited use,
>>> because it can then make itself appear to be a new device with a new
>>> MUD configuration. (This is of course true in general in a wireless
>>> context if the firmware can change the client's L2 address).
>>>
>>>
>>> Yes, configuration is intended to be removed when a device disconnects
>>> or a session terminates.  This would be considered normal garbage
>>> collection.  But whether or not you can simply replace the firmware and
>>> gain the same access will depend on how the MUD-URL is learned.  If it is
>>> in a manufacturer certificate, for instance, that's not something an
>>> attacker will easily replace.  If the assertion is coming via LLDP, or
>>> DHCP, then one has to apply the mitigations discussed in the security
>>> considerations section (and they are numerous).
>>>
>>
>> I'm not following you here. Say it's in a manufacturer certificate, what
>> stops me from getting my own certificate for Attacker LLC and then serving
>> a wide open policy? The mitigations don't really seem to do much to
>> counteract this.
>>
>>
>> I believe this point and one down below, where you write:
>>
>> This doesn't seem to address my concern, which is that there's no
>> 

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

Hi, Benoit,

On Mon, Feb 26, 2018 at 2:15 PM, Benoit Claise  wrote:

> The way I see it, we're going to fix comments forever.
>

Right. But my concern was that the text that we're reading for an up/down
vote can change after we read it, so I should be tracking the proposed text
changes.

That doesn't seem up/down. It seems like every other draft I've balloted on
as an AD :-)

Spencer


> And we need to resolve this one before the current ADs step down.
>
> Regards, Benoit
>
> This may not be my week, when it comes to comprehension. At least, I'm 0
> for 2 so far today.
>
> Are we still tuning text in this draft?
>
> https://www.ietf.org/standards/process/iesg-ballots/ says that the
> alternate balloting procedure is an up/down vote - we either agree to
> publish, or agree to send a document off for rework.
>
> If we're still resolving comments, one can imagine that we'd get to a
> one-Discuss situation, or even no Discusses, and wouldn't be doing an
> Alternate Ballot on Thursday.
>
> I don't object to resolving comments (actually, I find that lovely), but I
> don't know what we're doing.
>
> I've never seen the alternate balloting procedure executed (either as IESG
> scribe or as an IESG member), so maybe I don't get it, and other people
> have different expectations.
>
> Spencer
>
>
> ___
> OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

This may not be my week, when it comes to comprehension. At least, I'm 0
for 2 so far today.

Are we still tuning text in this draft?

https://www.ietf.org/standards/process/iesg-ballots/ says that the
alternate balloting procedure is an up/down vote - we either agree to
publish, or agree to send a document off for rework.

If we're still resolving comments, one can imagine that we'd get to a
one-Discuss situation, or even no Discusses, and wouldn't be doing an
Alternate Ballot on Thursday.

I don't object to resolving comments (actually, I find that lovely), but I
don't know what we're doing.

I've never seen the alternate balloting procedure executed (either as IESG
scribe or as an IESG member), so maybe I don't get it, and other people
have different expectations.

Spencer
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Ben Campbell's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Spencer Dawkins at IETF]

Following up on an obscure point ...

On Tue, Feb 6, 2018 at 11:40 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-mm-wg-effect-encrypt-17: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/
>
>
>
> --
> COMMENT:
> --
>
> This is a considerably better document than the previous versions I have
> reviewed. Thanks for all that work. But of course, I still have some
> comments
> :-)
>
> Substantive Comments:
>
> -2.2.2, 2nd paragraph: "... for example, many
>forms of communications (from isochronous/real-time to bulk/elastic
>file transfer) will take place over HTTP port 80 or port 443, so only
>the messages and higher-layer data will make application
>differentiation possible."
>
> I'm confused about the use of port 443 in that sentence; presumably
> traffic to
> 443 will be encrypted and not allow differentiation using higher-layer
> data.
>
> -2.2.4: This section lacks a discussion of the impact of encryption.
>
> -2.2.5, last paragraph: I understand that techniques that require endpoint
> cooperation might be out of scope, but the tone of this paragraph makes it
> sound like requiring endpoint cooperation is a negative. Is that the
> intent?
>
> -2.3, section title: The title is only partially evocative of the section
> content. I suggest adding "content filtering".
>
> -2.3.1: I think it might be worth mentioning that an "intercepting
> certificate"
> requires endpoints to be configured to trust that certificate. (I assume
> we are
> not talking about the more unsavory practice of certificates that
> misrepresent
> their subjects.
>
> -2.3.4 I concur with Adam that this section should explicitly mention
> "cross-site user tracking" as one of the common motivations for header
> insertion/enrichment. I think it should also include a mention of RFC 8165.
>
> -5.2: This section doesn't seem to include discussion of the impact of
> encryption.
>
> Editorial and nits:
>
> -IDNits finds a number of unused references, and a few other reference
> issues.
> Please check.
>
> - Abstract: 2nd sentence is hard to parse, and ends with a comma splice.
>
> - 1, 2nd paragraph: " The following informational
>documents consider the end to end (e2e) architectural principle, a
>guiding principle for the development of Internet protocols [RFC2775]
>[RFC3724] [RFC7754]."
>
> Is the comma correct? It currently reads along the lines of "The documents
> consider the e2e principle, and we think that it is a guiding
> principle...",
> but I think you might mean "The documents consider the e2e to be a guiding
> principle..."
>
> -1, 3rd paragraph: "... (including methods for network
>endpoints where applicable)..."
> Should that say "methods that rely on network endpoints"?
>
> -2.1.1: Please expand "CAIDA"
>
> -2.1.1: Paragraph starting with "
>When using increased encryption, operators lose a source of data that
>may be used to debug user issues."
> I don't think the operators are the ones using the encreased encryption in
> that
> sentence. Perhaps "When endpoints use increased encryption..." or even
> (When
> increased encryption is used..."
>
> -2.1.3, 2nd paragraph: "The ability to examine layers and payloads
>above transport provides a new range of filtering opportunities at
>each layer in the clear. "
> Should "new range" be "increased range"?
>
> -2.1.3, third paragraph: The last sentence seems out of place. Is the
> point of
> the paragraph to point out that the use of these monitoring techniques for
> DoS
> mitigation can't be distinguished from the use of them for privacy
> violation?
>
> -2.2.1: Please expand "QUIC" and add a citation.
>

QUIC started out as an acronym (and went through two or three variations),
but sometime during the chartering process, the expansion was dropped. QUIC
is both the working group name and abbreviation in
https://datatracker.ietf.org/wg/quic/about/.

But citations are good :-)


>
> -2.2.3, last sentence: Sentence fragment.
>
> -2.2.4, first sentence: Comma splice.
>
> -2.2.5, first paragraph: " Encryption of packet contents at a given
>protocol layer usually makes DPI processing of that layer and higher
>layers impossible. "
>
> This sentence seems misplaced; the section is not about DPI.
>
> -- same paragraph: I don't understand the point(s) of the last two
> sentences.
>
> -2.2.5, third paragraph: "The Enhanced