Hi Luigi, If you think that it would be useful to open up an IANA registry now, then I would not wait i.e. I’d publish the document as EXPERIMENTAL and update it into the standards track when you update RFC6830.
On the other hand, if the IANA registry is not needed at once then it could all wait. Personally, I find deferral options difficult to remember and pick up the threads - so I normally do things on the day and then adjust as required down the track - but that's more about my preferred way to work! kind regards, Geoff > On 28 Nov. 2016, at 8:12 pm, Luigi Iannone <[email protected]> wrote: > > Hi Geoff, >> On 28 Nov 2016, at 05:34, 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. > > Just for clarity. > > You suggest > > We publish this document as experimental now. Then we merge the standard > track update in the same document that updates 6830 as standard track. > > Am I right? > > An alternative option (with less work to do) is to keep this document on > hold until there will be the standard track update of 6830. > At that point, there will not be any issue in publishing the document as well > as standard track. > > In this way we do not need to work on merging the document with the 6830 > update and we still solve the issue you raised. > > Any thought ? > > ciao > > L. > > > >> >> 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
