Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <c027ee0d-8234-876a-0547-d12e49e42dc1@joelhalpern.com>
Date: Mon, 28 Nov 2016 15:34:57 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <DCEA0EAD-F1BA-4B58-9905-411A50FFEB4F@apnic.net>
References: <C636AF2FA540124E9B9ACB5A6BECCE6B7DF726F0@SZXEMA512-MBS.china.huawei.com>
 <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net>
 <c027ee0d-8234-876a-0547-d12e49e42dc1@joelhalpern.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/XTeEdjRnEwqgO3dle89iicgrOac>
Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" <zhang.xian@huawei.com>,
 lisp@ietf.org, rtg-ads@ietf.org,
 "jonathan.hardwick@metaswitch.com" <jonathan.hardwick@metaswitch.com>,
 draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson <jon.hudson@gmail.com>
Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt
Precedence: list

I am not fully aware of all the options here, but it strikes me that the =
IESG could publish this document as EXPERIMENTAL, consistent with =
RFC6830, and in the future whatever mechanism is used to update RFC6830 =
to Standards Track, the same document could UPDATE this document and =
place it on the standards track by virtue of the Update.

There may be other approaches as well, as this is _not_ an area where I =
would call myself an =E2=80=9Cexpert=E2=80=9D!

regards,

  Geoff



> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern <jmh@joelhalpern.com> =
wrote:
>=20
> You raise an interesting point Geoff.
>=20
> The documents are experimental.  As such, it is reasoanble for this =
document to be experimental, and for it merely to require IETF RFC for =
assignment, without restricting it to Standards Track RFCs.
>=20
> And while we are in the process of moving the LISP documents to =
Standards Track, that will take time.
>=20
> However, I would like to be able to have the right status in the =
documents when we get the upgrade done.  We can do a revision of this =
document as well, but that seems to be creating work.
>=20
> Any suggestions for how to thread this needly?
>=20
> Yours,
> Joel
>=20
> On 11/27/16 10:04 PM, Geoff Huston wrote:
>> Hello,
>>=20
>> I have been selected as the Routing Directorate reviewer for this =
draft.
>>=20
>> The Routing Directorate seeks to review all routing or =
routing-related
>> drafts as they pass through IETF last call and IESG review, and =
sometimes
>> on special request. The purpose of the review is to provide =
assistance to
>> the Routing ADs. For more information about the Routing Directorate,
>> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi=
r
>>=20
>> Although these comments are primarily for the use of the Routing ADs, =
it
>> would be helpful if you could consider them along with any other IETF =
Last
>> Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>>=20
>> Document: draft-ietf-lisp-type-iana-03.txt
>> Reviewer: Geoff Huston Review
>> Date: 28 November 2016
>> IETF LC End Date: not called
>> Intended Status: Standards Track
>>=20
>> Summary:
>>=20
>> I have significant concerns about this document and recommend that =
the
>> Routing ADs discuss these issues further with the authors and the =
IANA.
>>=20
>> Comments:
>>=20
>> Draft quality and readability.
>>=20
>> The third paragraph of the Introduction is unclear. Given that LISP =
itself
>> is an experimental specification it is hard to understand the =
distinction
>> being made between the "experimentation purposes" and some other
>> undescribed purpose which this reviewer can only conclude is also an
>> experimentation purpose. I suggest re-thinking the intent of this
>> paragraph and expressing it in simpler terms.
>>=20
>> In section 2, the use of the normative "MUST" seems to be =
inappropriate,
>> particularly when a non-normative "must" ius used in section 4 in an
>> identical context.
>>=20
>> Major Issues:
>>=20
>> It seems anomalous to me that a request to set up an IANA Registry =
for an
>> Experimental Protocol (RFC6830 is Experimental) is itself proposed to =
be a
>> Standards Track document.
>>=20
>> Furthermore, the document states that additional values be assigned =
via a
>> Standards Action. Again, it appears anomalous to me that a =
specification
>> of a parameter value of an experimental protocol be described by a
>> Standards Track action.
>>=20
>> If RFC6830 is revised and is re-published as a Standards Track
>> specification then these points are of course not relevant, but until =
such
>> a publication takes place, specifying an IANA parameter registry as a
>> Standards Track action for an experimental protocol seems to me to be
>> anomalous and should not proceed unless the IESG specifically agrees =
with
>> this approach. Alternatively RFC5226 could be further revised to
>> explicitly describe the guidelines as they relate to Experimental
>> Specifications (as distinct from experimental allocations within =
Standards
>> Track specifications), as this area appears to be unclear from my =
reading
>> of RFC5226.
>>=20
>> However it is not for me to resolve this issue, nor is it up to the =
draft
>> authors, or the LISP working group, as far as I can tell.  It is up =
to the IESG and
>> IANA to clarify this situation and allow IANA to be given clear =
directions
>> as to how to maintain parameter registries for experimental =
specifications
>> while they remain experiments.
>>=20
>>=20
>>=20