Dino, Med, please confirm if I am reading the thread properly:
I believe that the proposal is to make the small change below to 6833bis
and to drop the "updates" reference from 8113bis to 6833bis.
I believe Dino's question was whether Brian agreed that the combination
suggested would address his concern.
Yours,
Joel
On 12/20/18 2:55 PM, Brian E Carpenter wrote:
I may be missing something but I don't see how 8113bis can
logically cite 8113, which it replaces.
Frankly I think you've collectively created a plate of citation
spaghetti by not moving the IANA considerations for the type field
registry into 6830bis, which is where they naturally belong. If you
don't want to do that, I think you have to leave them in 8113bis and
simply lose the citation of 6833bis, which serves no purpose that
I can see.
Regards
Brian
On 2018-12-21 06:32, Dino Farinacci wrote:
I’ll make that change if Brian thinks it fixes the issues he raised.
Dino
On Dec 19, 2018, at 11:35 PM, <mohamed.boucad...@orange.com>
<mohamed.boucad...@orange.com> wrote:
Hi Dino,
OLD:
Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126].
NEW:
Values in the "Not Assigned" range can be assigned via Standards
Action [RFC8113].
Cheers,
Med
-----Message d'origine-----
De : Dino Farinacci [mailto:farina...@gmail.com]
Envoyé : mercredi 19 décembre 2018 19:00
À : BOUCADAIR Mohamed TGI/OLN
Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
draft-ietf-lisp-rfc8113bis....@ietf.org
Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
What does fixing in (1) mean?
Dino
On Dec 19, 2018, at 3:51 AM, <mohamed.boucad...@orange.com>
<mohamed.boucad...@orange.com> wrote:
Hi all,
Brian, whether to maintain the document standalone was discussed by the WG.
You may refer, for example, to the message from Deborah which clarifies this
point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
of the outcomes of that discussion is to add an "updates" header to 8113bis.
FWIW, one of the issues that led to that conclusion was whether to cite
rfc8113bis as normative in 6833bis (the approach I initially supported) and
agreed by Dino (https://www.ietf.org/mail-
archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
8113bis will lead to circular dependency. Which is a fair argument.
The "updates" tag was justified as follows:
(1)
RFC6833bis includes the following:
Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126].
That text is updated by RFC8113bis to be aligned with 8113:
Values can be assigned via Standards Action
(2)
RFC8113bis extends the type field to grab more bits/values when the
available types are exhausted. This is captured in 8113bis:
The values in the range 0-1023 are assigned via Standards Action.
This range is provisioned to anticipate, in particular, the
exhaustion of the LISP Packet types.
Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
"updates" header because (2) can be also seen as an extension.
Cheers,
Med
-----Message d'origine-----
De : Dino Farinacci [mailto:farina...@gmail.com]
Envoyé : mercredi 19 décembre 2018 06:37
À : Joel M. Halpern
Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
rfc8113bis....@ietf.org
Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
01
Mohmad to comment.
Dino
On Dec 18, 2018, at 8:49 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
That is the other fix he offered. Just remove the updates tag.
I will leav eit to you and the the authors to determine which is correct.
Yours,
Joel
On 12/18/18 11:43 PM, Dino Farinacci wrote:
8113bis should say that is it *extending* the type field so we can have
more types. The word “update” I always had a problem with because it can
be
interpreted as “replacing". Replacing something to fix a problem.
8113 is simply asking for one of the type value codepoint, so there can
be
another format to have more types.
Dino
On Dec 18, 2018, at 9:24 PM, Joel M. Halpern <j...@joelhalpern.com>
wrote:
Authors: that sounds like a reasonable addition to me?
Yours,
Joel
On 12/18/18 10:48 PM, Brian E Carpenter wrote:
On 2018-12-19 15:46, Joel M. Halpern wrote:
This is part of the package to move the coherent set of base LISP
specs
to PS.
The reason we did this rather than folding it into 6830bis / 6833bis
is
that we had originally simply cited 8113, and then realized that
needed
to move to PS along with everything else. It seemed (and is) simpler
to
do it separately rather than to further modify 6830bis / 6933bis.
As for why it updates 6833bis, that is because one of the cahnges in
moving the set to PS was to improve the split as to which information
belonged in which document.
OK, but I still don't find it logical The text doesn't explain which
part of
6833bis is impacted, and normally these days we require such an
explanation.
And if there is an impact, you're missing the opportunity of fixing
the
error
or gap in 6833bis, so the reader of 6833bis will be none the wiser
unless
you insert a reference to 8113bis.
On the other hand, if there is no error or gap, you don't need
"Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)
Brian
Yours,
Joel
On 12/18/18 9:25 PM, Brian Carpenter wrote:
Reviewer: Brian Carpenter
Review result: Ready with Issues
Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-lisp-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:
Summary: Ready with issues
--------
Comments:
---------
I note that this is being raised from Experimental to the standards
track.
Presumably that depends on the base LISP spec becoming PS.
Minor issues:
-------------
"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.
In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.
Since rfc6830bis (and rfc6833bis) are still under IESG review,
anything
in them that needs updating should be updated! The fact is that
rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
