From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <23037_1512483940_5A26AC64_23037_392_5_1512483939.26596.80.camel@orange.com>
References: <23037_1512483940_5A26AC64_23037_392_5_1512483939.26596.80.camel@orange.com>
MIME-Version: 1.0
Date: Tue, 5 Dec 2017 14:11:52 -0800
Message-ID: <CAMMESsytoQcwe-3Jd-gEc6mBe6_F=KfeEMxuR0WY7kh57KZx3A@mail.gmail.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>, bess-chairs@ietf.org, 
 thomas.morin@orange.com
Cc: bess@ietf.org
Content-Type: multipart/alternative; boundary="001a113d57cc46b513055f9f1faf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/luVdfkPycw5ZDrC_DaizbXM51_E>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
Precedence: list

--001a113d57cc46b513055f9f1faf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On December 5, 2017 at 9:25:39 AM, thomas.morin@orange.com (
thomas.morin@orange.com) wrote:

>
>
> (2) Document Status
>
>
> Why is this a Standards Track document? The Abstract/Introduction
> say
> that =E2=80=9Cthis document describes how Ethernet VPN (EVPN) can be used
> as an
> NVO solution and explores applicability of EVPN functions and
> procedures.=E2=80=9D -- if it=E2=80=99s just a description (as the text c=
learly
> is),
> and not a technical specification, then why it is not
> Informational?
> I can see how we could call it an Applicability Statement (rfc2026)
> and
> still publish it in the Standards Track. If we want to go that
> way, we
> would need some minor updates to make it clear that this is an
> Applicability Statement and is not intended to stand in for a
> Technical
> Specification. I am not clear on the process as it related to
> possible
> DownRefs (see below), but I=E2=80=99m willing to Last Call an Applicabili=
ty
> Statement in the Standards Track=E2=80=A6if that is what you want.
>
>
> Maybe the authors should s/describes/specifies/ to better reflect
> the
> content of the document.
> On the other hand, rfc2026 says "A Technical Specification is any
> description of a protocol, service, procedure, convention, or
> format."
> It seems to match as well.
>
>
> I agree that "specifies" is a better wording for the content of this
> document which does specify detailed procedures combining existing
> mechanisms. It certainly needs to be Standard Track.
>
Ok, that=E2=80=99s fine.

Alvaro.

--001a113d57cc46b513055f9f1faf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><p class=3D"gmail_quote" style=3D"color:#000">On D=
ecember 5, 2017 at 9:25:39 AM, <a href=3D"mailto:thomas.morin@orange.com">t=
homas.morin@orange.com</a> (<a href=3D"mailto:thomas.morin@orange.com">thom=
as.morin@orange.com</a>) wrote:</p> <blockquote type=3D"cite" class=3D"gmai=
l_quote"><span><div><div></div><div><br><blockquote type=3D"cite">
<br><blockquote type=3D"cite">(2) Document Status
<br>
<br>
<br>Why is this a Standards Track document?  The Abstract/Introduction
<br>say
<br>that =E2=80=9Cthis document describes how Ethernet VPN (EVPN) can be us=
ed
<br>as an
<br>NVO solution and explores applicability of EVPN functions and
<br>procedures.=E2=80=9D  -- if it=E2=80=99s just a description (as the tex=
t clearly
<br>is),
<br>and not a technical specification, then why it is not
<br>Informational?
<br>I can see how we could call it an Applicability Statement (rfc2026)
<br>and
<br>still publish it in the Standards Track.  If we want to go that
<br>way, we
<br>would need some minor updates to make it clear that this is an
<br>Applicability Statement and is not intended to stand in for a
<br>Technical
<br>Specification.  I am not clear on the process as it related to
<br>possible
<br>DownRefs (see below), but I=E2=80=99m willing to Last Call an Applicabi=
lity
<br>Statement in the Standards Track=E2=80=A6if that is what you want.
<br></blockquote>
<br>Maybe the authors should s/describes/specifies/ to better reflect
<br>the =20
<br>content of the document.
<br>On the other hand, rfc2026 says &quot;A Technical Specification is any =
=20
<br>description of a protocol, service, procedure, convention, or
<br>format.&quot;
<br>It seems to match as well.
<br></blockquote>
<br>I agree that &quot;specifies&quot; is a better wording for the content =
of this
<br>document which does specify detailed procedures combining existing
<br>mechanisms.  It certainly needs to be Standard Track.
<br>
</div></div></span></blockquote><p>Ok, that=E2=80=99s fine.</p><p>Alvaro.</=
p><p><br></p><br><div class=3D"bloop_sign"></div></body></html>

--001a113d57cc46b513055f9f1faf--