[RTG-DIR]Re: RtgDir Last Call review: draft-ietf-pals-ple

["Christian Schmutzer (cschmutz)" <[e-mail]>]

Hi Tal,

thank you very much for your review and suggestions! I will work with my co-authors to address your comments and come back to this thread

regards
Christian

On 15.05.2024, at 12:18, Andrew G. Malis <[e-mail]> wrote:

Tal,

Thank you very much for the review!

Authors,

Please respond to the points in the review (copying the working group) and once you and Tal have agreement on what the updates should be, update your draft. Once the draft has been updated, I will end the WG last call and start the publication process.

Thanks,
Andy


On Wed, May 15, 2024 at 4:20 AM Tal Mizrahi <[e-mail]<mailto:[e-mail]>> 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
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-pals-ple-04
Reviewer: Tal Mizrahi
Intended Status: Standards Track

Summary:
I have some concerns about this document that I think should be
resolved before publication.

The draft is well-written and clear from a grammatical and structural
perspective. However, there is a very long list of normative
references that are cited in almost every paragraph of the document,
making it very difficult to follow for a reader who is somewhat
familiar with the area but is not an expert in the area.

Issues:
- The target audience of the document should be clarified, preferably
in the abstract. On a related note, throughout the document it is a
bit difficult to distinguish between requirements defined for
operators vs. requirements defined for implementers. Perhaps the
authors could give some thought as to whether this issue can be
mitigated.
- The security considerations should be more detailed. The cited
references are a good start, but the following issues should also be
discussed:
  - The requirement for synchronization is potentially a
vulnerability. An on-path attacker may compromise the synchronization,
and thus compromise the service. You may want to take a look at RFC
7384.
  - The requirements for low jitter, low loss and bandwidth
reservation (section 8) are also potentially an attack vector. You may
take a look at RFC 9055 for example.
- The following two endpoint behaviors are defined in the IANA
considerations section, but not defined anywhere in the document.
These endpoint behaviors should either be removed or specified in
detail:
End.DX1 with NEXT-CSID
End.DX1 with REPLACE-CSID
- Regarding the following paragraph, I wonder whether it is necessary
to define the exact clock frequency in an IETF document. Even ITU-T
G.8261 and IEEE 1588 do not define a specific clock frequency.
Interoperability does not necessarily require both endpoints to have
the same clock frequency.
      For bit-streams up to 200 Gbps the frequency of the
      clock used for generating timestamps MUST be 125 MHz based on a
      the common clock I.  For bit-streams above 200 Gbps the frequency
      MUST be 250 MHz.

Nits:
- "principals" => "principles" ?