On 28 Nov 2016, at 4:58, Geoff Huston wrote:
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.
FYI, dtnrg had his specs as experimental. After some good
experimentation with wg managed registries, we end up creating an RFC to
register all the parameters. That RFC (6255) was Informational.
Marc.
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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
