Hi,
I reviewed draft-ietf-pce-pcep-ls-01 through the lens of draft-bonica-
gendispatch-exp. Of course, that document is only a work in progress,
and even if it were published as an IETF consensus RFC, it would only be
guidance. But you may find this review helpful to smooth the passage of
your draft through IETF and IESG review.
You could address the points below just by beefing up existing text. Or you
might add a new section ("Experimental Considerations"). That's up to you.
draft-bonica-gendispatch-exp suggests that all Experimental protocol
drafts in the IETF stream should:
* Explain why the specification is presented as Experimental and not
for publication on the Standards Track.
>> I don't see this explained. Indeed, while the Abstract makes a
statement about this being Experimental, the main text doesn't get
to that point until Section 1.1.
I suggest that:
o In the Introduction, in the paragraph that begins "This document
describes how ..." or in a new paragraph immediately after, you
state that the new PCEP message format is presented as
Experimental and say (briefly) why, perhaps supplying a forward
reference to Section 1.1.
o If you can find a very few words, you extend the statement in the
Abstract to say why Experimental.
* Describe the experiment in detail, so that it can be replicated by
non-collaborating parties and recognized when it is seen in
deployments.
>> This seems well covered.
* Describe how the experiment is safeguarded so that it does not
harm the Internet or interfere with its established operations.
- It should indicate how messages or protocol data units are
identified and associated with the experiment.
>> This seems well covered.
- It should describe how backward compatibility is ensured by
non-participating deployments using pre-existing standardized
mechanisms to discard or ignore the experiment.
>> This seems well covered.
- It should explain how the experiment is controlled so that it
does not "leak out" into the wider Internet.
>> This seems well covered.
* List what configuration knobs should be provided on experimental
implementations
>> Section 12.1 has this covered.
* Include a date at which the experiment will be terminated.
>> This is in 1.1
* Include metrics and observations that will be collected during the
experiment.
>> Information is a bit short. The main metric seems to be
implementation and deployment. There is no mention of what
experience should be gathered to help assess the success of the
deployments.
* Include criteria by which success of the experiment will be
determined.
>> This is also short of information. The simple statement that the
results of implementation and deployment will lead to this document
to be updated and refined and moved to the Standards Track. There
needs, I think, to be a little bit more said about what will be
looked for in those results (which refers back to the previous
point).
* Explain how reports of the success or failure of the experiment
will be brought to the IETF, what information should be collected
and reported (see Section 3), and possibly suggest a template for
reporting experimental results.
>> This is entirely missing. You say "the RFC authors will attempt to
determine how widely this has been implemented and deployed," but
you should suggest a way this information can be collected (for
example, the WG wiki) and what would constitute a success (i.e.,
what threshold you are aiming for). I think you might also ask for
a bit more information to be gathered (network technology, size of
network, volume of traffic, ...).
* Suggest planned next steps if the experiment is fully or partially
successful.
>> This seems well covered.
Hope this helpful.
Cheers,
Adrian
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
