Yes, 15 is the only new type at the moment.
But the existence of a request for new types raises the point that there
may well be others. So creating a registry seems the right thing to do.
Since the registry needs to allow experimental entries (the current
protocol), it seems that we are better served getting it established now.
Yours,
Joel
On 1/30/17 5:10 PM, Alvaro Retana (aretana) wrote:
Joel:
Hi!
To clarify, there are two Registries being defined: LISP Packet Types
and Sub-Types.
I don’t have an issue with the Sub-Types registry, which is the one that
allows you to get new functionality up and going, with or without an RFC
– it currently has a FCFS registration policy. Maybe a little too open,
but if this is what the WG wants, then I’m ok with it.
The LISP Packet Types Registry is the one I have an issue with being
defined in this document. It seems like the main motivation of the
document is the new LISP Shared Extension Message Type, and that
creating the registry only serves to assign type 15 to it. But any
other extensions would make use of the Sub-Types registry, and not this one.
Maybe I’m missing the subtleties of which space is used for what...
Thanks!
Alvaro.
On 1/30/17, 4:52 PM, "Joel M. Halpern" <[email protected]
<mailto:[email protected]>> wrote:
With regard to status, I think we can work with you.
But we really want to establish the registry now.
We already have proposals for code points beyond the experimental RFCs,
and requests for room to experiment without writing an RFC.
As far as I can tell, the Working Group intent is that the registry
allow reservation by experimental and informational RFCs, not just
standards track RFCs. We can fix that.
With regard to the revision to the base documents, to get them on the
standards track, one of the important fixes is to stop claiming that
the
RFC defines all the values, and just update the registry entries where
appropriate to reference the new RFC (once we have it.)
The rush is simply that it is already getting hard to keep track. We
should have established a registry in the first place. So we are doing
so now.
On 1/30/17 4:46 PM, Alvaro Retana wrote:
Alvaro Retana has entered the following ballot position for
draft-ietf-lisp-type-iana-04: Discuss
When responding, please keep the subject line intact and reply
to all
email addresses included in the To and CC lines. (Feel free to
cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I have a couple of points I think we should DISCUSS before
moving this
document forward: the intended status and the definition of the
registry.
(1) Intended Status: The Datatracker indicates that the Intended RFC
status for this document is Proposed Standard (as does the Shepherd
WriteUp and the IETF LC), but the header on the document says
Experimental. I note that the document header was changed after a
discussion on the WG list resulting from the RTG Directorate
review [1],
but that happened after the WGLC. Which is the right status?
(2) LISP Packet Types Registry Definition: It seems very odd to
me that
the LISP Packet Types Registry uses Standard Action as the
registration
policy given that the LISP work is currently Experimental -- and
that the
other references in it would in fact be from an Experimental RFC
(rfc6380). I know there's work on rfc6830bis (in the Standards
Track),
but I think it would be better to have this registry defined in
the base
specification (rfc6833bis, in this case)...or to wait for the
publication
of that document to progress this one.
I think there's nothing procedurally wrong with having an
Experimental
RFC define a Standard Action Registry and populate part of it with
references to Experimental RFC. However, the solution just
doesn't seem
clean to me -- so I would like to hear the justification for the
rush
(and not waiting for rfc6380bis/rfc6388bis).
I have no issue with a document making use of the Code Point to
describe
the new LISP Shared Extension Message Type (without creating the
Registry). But given that the base LISP specification is still
Experimental, then this document should be too. There shouldn't
be an
issue with changing the Status of this document (in-place) once
rfc6380bis/rfc6388bis progress.
There's also the issue that RFC6830 (and rfc6833bis) contain the
following text: "This section will be the authoritative source for
allocating LISP Type values..." Which means that (if the
registry is to
be defined here), this document should at least Update RFC6830...
In summary, I think that the correct Status for this document is
Experimental. I also think that it would be better to wait for
rfc6833bis to define the Registry.
[1]
https://mailarchive.ietf.org/arch/msg/lisp/m1EicCexdX1GI183pba-mcHJM7g/?qid=ada479dce3c434bfaf948b0ee8240996
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
a. The Introduction justifies the extension as being used for
experiments: "Because of the limited type space [RFC6830] and
the need to
conduct experiments to assess new LISP extensions, this document
specifies a shared LISP extension message type". It seems clear
later in
the text that the intent of the new message type is not just for
experimentation, but that in fact the intent is for new
functionality to
be deployed using it. Is that correct? If it is, then please
make it
clear -- if not, then I would like to see how the authors propose a
transition to happen between the experimental space and the
production
one.
b. The IANA Considerations Section says that "The value 15 is
reserved
for Experimental Use [RFC5226]." But it is being assigned to
the new
LISP Shared Extension Message.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
