Re: [PANRG] I-D Action: draft-irtf-panrg-what-not-to-do-07.txt

Theresa Enghardt <ietf@tenghardt.net> Fri, 17 January 2020 09:14 UTC

Date: Fri, 17 Jan 2020 10:14:29 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CAKKJt-ev=Yr9_qruoA7DXdKWiwfhcf=SS_G8RMYe5fGY9S_zAw@mail.gmail.com>
References: <157915359377.21812.18011231046083451973@ietfa.amsl.com> <CAKKJt-ev=Yr9_qruoA7DXdKWiwfhcf=SS_G8RMYe5fGY9S_zAw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: panrg@irtf.org
From: Theresa Enghardt <ietf@tenghardt.net>
Message-ID: <30089CEC-AEFD-48B6-BD8E-9D425DD33570@tenghardt.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/XO-DuQ1P8PtcFhKvVA2KgrOBjOM>
Subject: Re: [PANRG] I-D Action: draft-irtf-panrg-what-not-to-do-07.txt
Precedence: list

Hi,

Am 16. Januar 2020 06:58:44 MEZ schrieb Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>:
>   5. Med asked about adding a new Lesson to section 2, as "Some of the
>failed proposals require that the full path should be capable to
>support a
>new feature (e.g., resource reservation). An alternate approach to
>focus
>only on the segment where this is useful would suffice: for example, if
>signaling is done only with the access point better experience would be
> observed immediately without requiring in the full path compliance". I
>THOUGHT providing benefits during incremental deployment was captured
>in
>the existing lessons, but it's certainly not plainly stated. I
>paraphrased
>this suggestion in, in a new  Section 2.3 and updated Section 3 to
>include
>   it as an Invariant.

I think this makes sense as a lesson and it sounds like an Invariant to me as well.

Best,
Theresa

[PANRG] I-D Action: draft-irtf-panrg-what-not-to-… internet-drafts
Re: [PANRG] I-D Action: draft-irtf-panrg-what-not… Spencer Dawkins at IETF
Re: [PANRG] I-D Action: draft-irtf-panrg-what-not… Theresa Enghardt