Hi Geoff,
Actually, the proposed status of this document was not triggered by the action
to create the IANA register (that can be done via an Informational Document)
but with the action to specify a shared LISP extension message format and
assign a codepoint (15) for that purpose.
FWIW, this point was mentioned in the write-up:
==
This document targets to follow standard track, hence aiming at the
initial level of "Proposed Standard".
I personally argued with the authors that usually documents
aiming at creating IANA registries are "informational".
Yet, as the authors rightfully pointed out, the document also
proposes the experimental packet format, for which standard
track looks more appropriate.
As a shepherd of the document I am fine keeping this
intended status. To be noted that the document passed the
WGLC with the such intended status. No concern was raised by the
WG members. As for the IETF process, it is up to the
IESG to assign the most appropriate status to this document.
==
That's said, I'm OK to change the status to EXP if that is more appropriate.
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : Geoff Huston [mailto:[email protected]]
> Envoyé : lundi 28 novembre 2016 19:54
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Zhangxian (Xian); [email protected]; [email protected]; [email protected];
> [email protected]; [email protected];
> Jon Hudson
> Objet : Re: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt
>
> You appear to have misunderstood me - its _not_ that this draft seeks to
> create an
> IANA registry for an experimental specification that I found to be
> anomalous. What
> I found anomalous was that the document proposing such an action was
> itself proposed
> to be a Standards Track document.
>
> Clear now?
>
> thanks,
>
> Geoff
>
>
>
> > On 29 Nov. 2016, at 12:43 am, <[email protected]>
> <[email protected]> wrote:
> >
> > Hi Goeff,
> >
> > I have one comment about this part of your review:
> >
> >> 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.
> >
> > FWIW, I'm aware of an IANA registry for an experimental protocol that
> you can check here:
> > http://www.iana.org/assignments/tcp-parameters/tcp-
> parameters.xhtml#mptcp-option-subtypes
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : lisp [mailto:[email protected]] De la part de Geoff Huston
> >> Envoyé : lundi 28 novembre 2016 04:04
> >> À : Zhangxian (Xian); [email protected]
> >> Cc : [email protected]; [email protected]; [email protected];
> >> [email protected]; Jon Hudson
> >> Objet : [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt
> >>
> >> 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
