Hi, Geoff's proposal is also fine by me.
Cheers, Christian. -----Message d'origine----- De : [email protected] [mailto:[email protected]] Envoyé : lundi 28 novembre 2016 14:59 À : Dino Farinacci; Geoff Huston Cc : Joel M. Halpern; [email protected]; Zhangxian (Xian); [email protected]; [email protected]; [email protected]; [email protected]; Jon Hudson Objet : RE: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt Re-, Works for me, too. Cheers, Med > -----Message d'origine----- > De : Dino Farinacci [mailto:[email protected]] Envoyé : lundi 28 > novembre 2016 07:11 À : Geoff Huston Cc : Joel M. Halpern; > [email protected]; Zhangxian (Xian); [email protected]; [email protected]; > [email protected]; draft-ietf-lisp-type- > [email protected]; Jon Hudson Objet : Re: [lisp] [RTG-DIR] RtgDir > review: draft-ietf-lisp-type-iana- 03.txt > > 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
