Response inline, some text elided.
On 2/9/18 11:21 AM, MORTON, ALFRED C (AL) wrote:
Adam, please see two further suggestions, in-line:
From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
A goal is protecting end-user
data -- but at the same time not making the network inoperable or
I fear this sentence falls back to the hyperbolic tone that plagued version
-10 of this document. I suggest something more along the lines of "...not
forcing changes to the way networks have historically been operated and
managed" or something similar.
I'd like Al to weigh in one this change from an operator perspective.
To me, this reads like both sides are being weighed equally. He may
have another suggestion that works to help with the tone you are
looking for, but also acks the impact to operators to further the
Since this is the section on SFC, and describing the failure of the
classifier function [RFC7665], we are talking about the present-day
designs and possible loss of functionality.
I suggest (last phrase, with the entire paragraph included for context):
There are also mechanisms provided to protect security and privacy.
In the SFC case, the layer below a network service header can be
protected with session encryption. A goal is protecting end-user
data, while retaining the intended functions of [RFC7665] at
the same time.
OPSAWG mailing list