On 08/07/2025 21:35, Padma Pillay-Esnault wrote:
Hi Gorry
Thank you for your careful review and thoughtful DISCUSS and COMMENT
feedback. We appreciate the time and attention you've given to
improving the clarity and quality of the document.
Thansk for getting back promptly. Please see replies below, marked as [GF].
On Wed, Jul 2, 2025 at 8:26 AM Gorry Fairhurst via Datatracker
<nore...@ietf.org> wrote:
>
> Gorry Fairhurst has entered the following ballot position for>
draft-ietf-lisp-te-21: 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-te/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> DISCUSS 1: I'd like to understand why this has been requested for
publication
> as EXP? I may have missed this, but I didn't see any new protocol
definitions.
> I do note it was chartered as an experimental extension, yet I see no
> explanation of why this is an experiment, nor how that experiment
may in the
> future be declared as a success or failure. Whatever the reason, can
this
> reason to be noted in the abstract and to be described in the
introduction?
>
>
> DISCUSS 2: Since this is targeting EXP, what is the nature of the EXP
> specification: is it for a limited duration? A limited use-case? A
limited
> scope of deployment? i.e., what is the experiment and can this
document define
> implicit or explicit success/failure criteria, and an outcome that
can be used
> as the basis for a future recommendation to the IETF community?
>
/
PPE > indeed this has come up in a couple of the reviews of other
LISP drafts as well and we propose to add a similar text for
clarification for this draft:
“This document is part of a development effort to include Traffic
engineering in LISP. It is not part of an "experiment", as not all
experimental RFCs are necessarily part of an experiment. It is rather
about the maturity level of the technology.”
This makes it clear that the designation reflects maturity rather than
a bounded experiment, and that the document does not define explicit
success/failure criteria./
[GF] Citing one EXP LISP RFC (chosen mostly at random), RFC 7215 says...
"This experimental document describes deployment considerations.
These considerations and the LISP specifications have areas that
require additional experience and measurement. LISP is not
recommended for deployment beyond experimental situations. Results
of experimentation may lead to modifications and enhancements of LISP
mechanisms. Additionally, at the time of this writing there is no
standardized security to implement."
- Adapting some of that framework could be one way to supply the text that I
hope for.
>
> DISCUSS 3: Section 7 is about a topic that I do not see explained.
If this is
> important enough to include, please specify this. The informational
reference
> to the ELP-probing mechanism details in
[I-D.filyurin-lisp-elp-probing] seems
> insufficient and since this reference has expired (in 2018) as a
non-WG I-D,
> can the whole section be removed?
>
/PPE> Thank you for this observation. We are proposing some clarifying
text in the draft that the ELP-probing is a hop by hop RLOC probing
which is a base mechanism described in RFC9301. It can be across the
entire ELP (meaning each RLOC-probe hop metrics were summed up to give
you metrics on the entire ELP). The above draft can be revived if
there is an interest.
/
Right, I'm not too concerned about whether the expired I-D is
resurrected. As an inidvidual I-D it does not have much weight, but I
wouldn't want this section to be used as justification to adopt (or not)
future work, I'd rather it just stated what was needed - and that this
explained this probe concept.
I'd need to read the text to see if this addressed, but your proposal
seems like a useful direction.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'd strongly encourage changing the opening sentence of section 2,
to insert
> the word “Experimental” before extension, "Informational" if the
document were
> changed to target this.
>
> Please consider the following:
>
> - Please do expand the word LISP in the title
>
> - Please expand LISP in the abstract.
> - Please also define all abbreviations on first use, I expect this
will hardly
> increase the word count much and can save reader pain.
>
>
/PPE> The protocol acronym is used in many RFCs in IETF and we wish to
keep it as it.
Agree on expanding in the abstract and in the text for the abbreviations.
/
Thanks
[GF] Yes, it would surely be to say LISP In the title, if that were
expanded in the Abstract :-).
[GF] I also don't see why Traffic Engineering is capitalised in the
Abstract?
[GF] Note: You may also like to refer to RFC 9300 in the definition of
LISP in the Introduction?
> Padma (and on behalf of co-authors)
I look forward to seeing the proposed text.
Best wishes,
Gorry
_______________________________________________
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org
