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

--===============9196626401487460827==
Content-Type: multipart/alternative; boundary="000000000000343fbc06187b72de"

--000000000000343fbc06187b72de
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Tal Mizrahi <tal.mizrahi.phd@gmail.=
com>
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" =3D> "principles" ?
>

--000000000000343fbc06187b72de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Tal,<div><br></div><div>Thank you very much for the review=
!</div><div><br></div><div>Authors,</div><div><br></div><div>Please respond=
 to the points in the review (copying the working group) and once you and T=
al have agreement on what the updates=C2=A0should be, update your draft. On=
ce the draft has been updated, I will end the WG last call and start the pu=
blication process.</div><div><br></div><div>Thanks,</div><div>Andy</div><di=
v><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Wed, May 15, 2024 at 4:20=E2=80=AFAM Tal Mizrahi &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I have been selected as the Routing Directorate reviewer for this<br>
draft. The Routing Directorate seeks to review all routing or<br>
routing-related drafts as they pass through IETF last call and IESG<br>
review, and sometimes on special request. The purpose of the review is<br>
to provide assistance to the Routing ADs. For more information about<br>
the Routing Directorate, please see<br>
<a href=3D"https://wiki.ietf.org/en/group/rtg/RtgDir" rel=3D"noreferrer" ta=
rget=3D"_blank">https://wiki.ietf.org/en/group/rtg/RtgDir</a><br>
<br>
Document: draft-ietf-pals-ple-04<br>
Reviewer: Tal Mizrahi<br>
Intended Status: Standards Track<br>
<br>
Summary:<br>
I have some concerns about this document that I think should be<br>
resolved before publication.<br>
<br>
The draft is well-written and clear from a grammatical and structural<br>
perspective. However, there is a very long list of normative<br>
references that are cited in almost every paragraph of the document,<br>
making it very difficult to follow for a reader who is somewhat<br>
familiar with the area but is not an expert in the area.<br>
<br>
Issues:<br>
- The target audience of the document should be clarified, preferably<br>
in the abstract. On a related note, throughout the document it is a<br>
bit difficult to distinguish between requirements defined for<br>
operators vs. requirements defined for implementers. Perhaps the<br>
authors could give some thought as to whether this issue can be<br>
mitigated.<br>
- The security considerations should be more detailed. The cited<br>
references are a good start, but the following issues should also be<br>
discussed:<br>
=C2=A0 - The requirement for synchronization is potentially a<br>
vulnerability. An on-path attacker may compromise the synchronization,<br>
and thus compromise the service. You may want to take a look at RFC<br>
7384.<br>
=C2=A0 - The requirements for low jitter, low loss and bandwidth<br>
reservation (section 8) are also potentially an attack vector. You may<br>
take a look at RFC 9055 for example.<br>
- The following two endpoint behaviors are defined in the IANA<br>
considerations section, but not defined anywhere in the document.<br>
These endpoint behaviors should either be removed or specified in<br>
detail:<br>
End.DX1 with NEXT-CSID<br>
End.DX1 with REPLACE-CSID<br>
- Regarding the following paragraph, I wonder whether it is necessary<br>
to define the exact clock frequency in an IETF document. Even ITU-T<br>
G.8261 and IEEE 1588 do not define a specific clock frequency.<br>
Interoperability does not necessarily require both endpoints to have<br>
the same clock frequency.<br>
=C2=A0 =C2=A0 =C2=A0 For bit-streams up to 200 Gbps the frequency of the<br=
>
=C2=A0 =C2=A0 =C2=A0 clock used for generating timestamps MUST be 125 MHz b=
ased on a<br>
=C2=A0 =C2=A0 =C2=A0 the common clock I.=C2=A0 For bit-streams above 200 Gb=
ps the frequency<br>
=C2=A0 =C2=A0 =C2=A0 MUST be 250 MHz.<br>
<br>
Nits:<br>
- &quot;principals&quot; =3D&gt; &quot;principles&quot; ?<br>
</blockquote></div>

--000000000000343fbc06187b72de--


--===============9196626401487460827==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls
aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBhbHMtbGVhdmVAaWV0Zi5vcmcK

--===============9196626401487460827==--