Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Dan Romascanu <dromasca@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 17 Oct 2019 08:15:32 +0300
Message-Id: <82AC1D76-4D83-4B59-AFFE-40429B14852D@gmail.com>
References: <22F10988-DB4D-4C2A-A2DA-D677CE396122@juniper.net>
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "idr@ietf.org" <idr@ietf.org>,
 "draft-ietf-idr-rfc8203bis.all@ietf.org"
 <draft-ietf-idr-rfc8203bis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
In-Reply-To: <22F10988-DB4D-4C2A-A2DA-D677CE396122@juniper.net>
To: John Scudder <jgs@juniper.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/x0IK9KGnK6xMuDvYLVAcqLZ8_NY>
Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-rfc8203bis-04
Precedence: list

Hi John,

Thanks for addressing the issues raised in the OPS-DIR review. Looks good no=
w.=20

Regards,

Dan


Sent from my iPhone

> On 17 Oct 2019, at 1:32, John Scudder <jgs@juniper.net> wrote:
>=20
> =EF=BB=BFHi Dan,
>=20
> Thanks for your review. We=E2=80=99ve just uploaded version -05 that takes=
 into account your feedback. Some comments below.
>=20
>> On Oct 1, 2019, at 10:01 AM, Dan Romascanu via Datatracker <noreply@ietf.=
org> wrote:
>>=20
>> Reviewer: Dan Romascanu
>> Review result: Has Issues
>>=20
>> This document defines an enhancement to the BGP Cease NOTIFICATION messag=
e
>> "Administrative Shutdown" and "Administrative Reset" subcodes for operato=
rs to
>> transmit a short freeform message to describe why a BGP session was shutd=
own or
>> reset.  This document updates RFC 4486 and obsoletes RFC 8203 by defining=
 an
>> Extended BGP Administrative Shutdown Communication to improve communicati=
on
>> using multibyte character sets.
>>=20
>> It's clear and rather straightforward, so a full RFC 5706 review would no=
t
>> apply. However, I have some questions and issues that I would suggest to b=
e
>> clarified before advancement and approval.
>>=20
>> 1. The document will obsolete, if approved, [RFC 8203]. The rationale for=
 this
>> change is currently relegated in Appendix B. I suggest to be moved up for=
ward
>> in the document, in the introduction section.
>=20
> We didn=E2=80=99t want to hoist all of Appendix B up into the main text be=
cause in the long run, it seems better to keep the main body of the document=
 down to just the facts an implementor needs to know. However, we did add a p=
ointer to Appendix B in the introduction.
>=20
>> 2. The 'Changes to RFC 8203' section should include an explicit list of t=
he
>> changes such as length field and usage of multibyte character sets.
>=20
> Done, in Appendix B. The only actual change is the permitted length, multi=
byte character sets were previously supported.
>=20
>> 3. I do not know how widely deployed RFC 8203 may be, but we cannot exclu=
de
>> that some versions do exist out there. I suggest that the Operational
>> Considerations sections include some information about what caution need t=
o be
>> taken by the operators when migrating from supporting RFC 8203 to the new=
 RFC.
>=20
> New text added per your suggestion.
>=20
>> 4. What does 'an invalid length value' mean in 'Error Handling' now? Prev=
iously
>> RFC 8203 had a requirement that 'The length value MUST range from 0 to 12=
8
>> inclusive.' This does not exist any longer now.
>=20
> Good point! Fixed.
>=20
> Thanks,
>=20
> =E2=80=94John
>=20