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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to