I think this is a good and expedient suggestion. Dino
> On Nov 27, 2016, at 8:34 PM, Geoff Huston <[email protected]> wrote: > > 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 “expert”! > > regards, > > Geoff > > > >> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern <[email protected]> wrote: >> >> You raise an interesting point Geoff. >> >> 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. >> >> And while we are in the process of moving the LISP documents to Standards >> Track, that will take time. >> >> 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. >> >> Any suggestions for how to thread this needly? >> >> Yours, >> Joel >> >>> On 11/27/16 10:04 PM, Geoff Huston wrote: >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this draft. >>> >>> 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 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>> >>> 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. >>> >>> 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 >>> >>> Summary: >>> >>> I have significant concerns about this document and recommend that the >>> Routing ADs discuss these issues further with the authors and the IANA. >>> >>> Comments: >>> >>> Draft quality and readability. >>> >>> 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. >>> >>> 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. >>> >>> Major Issues: >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> >>> > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
