[Pals] Re: Francesca Palombini's Discuss on draft-ietf-pal s-ple-13: (with DISCUSS and COMMENT)

--===============3845233022833397472==
Content-Type: multipart/alternative; boundary="000000000000aba33906286ff7b7"

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

Francesca,

Thanks for your review and comments. As a PALS WG chair, I just have a
comment on your DISCUSS regarding the reference to RFC 3985. Our standing
WG practice has been to refer informatively to 3985 in standards-track
RFCs. If you look at https://datatracker.ietf.org/doc/rfc3985/referencedby/=
,
you'll see that except for four RFCs with downrefs, all of the references
in standards-track RFCs (and most Informational RFCs as well) have been
informative (and as you can see, there have been many). So this draft
follows established WG practice.

Thanks,
Andy


On Wed, Dec 4, 2024 at 5:41=E2=80=AFAM Francesca Palombini via Datatracker =
<
[email protected]> wrote:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-pals-ple-13: 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-positio=
ns/
> 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-pals-ple/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document.
>
> Please let me know if the working group has already had a discussion on t=
he
> following references, it is entirely possible that this was discussed and
> agreed upon, in which case thank you for letting me know and pointing me
> to the
> discussion.
>
> I believe the following references should be normative instead of
> informative.
> - RFC 3985 (which is informational, so if we agree the IESG also has to
> approve
> the downref that hasn't been called out in IETF Last Call) - RFC 3550
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This is non-blocking because I am not sure about the resolution. Hopefull=
y
> discussion with the authors and the responsible AD will help.
>
> I was puzzled to see the following paragraph in Section 7.2.2:
>
> > The recovered clock MUST comply with the jitter and wander requirements
> applicable to the type of attachment circuit, specified in: > > [G.825] a=
nd
> [G.823] for SDH > > [GR253] for SONET > > [G.8261] for synchronous
> Ethernet > >
> [G.8251] for OTN
>
> and at the same time all of these references are informative. I understan=
d
> that
> depending on which of these you are considering, the others might be
> unnecessary to read, however with the requirement text I still feel those
> would
> have made more sense as normative references.
>
> Note that a similar comment could be made for the following text in Secti=
on
> 3.2, motivating the need for [G.8262] and [G.8261.1] being normative:
>
> > While using external timing inputs (aka BITS [ATIS-0900105.09.2013]) or
> synchronous Ethernet as defined in [G.8261] the characteristics and limit=
s
> defined in [G.8262] have to be considered. > > While relying on precision
> time
> protocol (PTP) as defined in [G.8265.1], the network limits defined in
> [G.8261.1] have to be considered.
>
>
>
>

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

<div dir=3D"ltr">Francesca,<div><br></div><div>Thanks for your=C2=A0review =
and comments. As a PALS WG chair, I just have a comment on your DISCUSS reg=
arding the reference to RFC 3985. Our standing WG practice has been to refe=
r informatively to 3985 in standards-track RFCs. If you look at=C2=A0<a hre=
f=3D"https://datatracker.ietf.org/doc/rfc3985/referencedby/">https://datatr=
acker.ietf.org/doc/rfc3985/referencedby/</a>, you&#39;ll see that except fo=
r four RFCs with downrefs, all of the references in standards-track RFCs (a=
nd most Informational RFCs as well) have been informative (and as you can s=
ee, there have=C2=A0been many). So this draft follows established WG practi=
ce.</div><div><br></div><div>Thanks,</div><div>Andy</div><div><br></div></d=
iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Wed, Dec 4, 2024 at 5:41=E2=80=AFAM Francesca Palombi=
ni via Datatracker &lt;<a href=3D"mailto:[email protected]">[email protected]=
</a>&gt; wrote:<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">=
Francesca Palombini has entered the following ballot position for<br>
draft-ietf-pals-ple-13: Discuss<br>
<br>
When responding, please keep the subject line intact and reply to all<br>
email addresses included in the To and CC lines. (Feel free to cut this<br>
introductory paragraph, however.)<br>
<br>
<br>
Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/statement=
s/handling-ballot-positions/" rel=3D"noreferrer" target=3D"_blank">https://=
www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/</a> <b=
r>
for more information about how to handle DISCUSS and COMMENT positions.<br>
<br>
<br>
The document, along with other ballot positions, can be found here:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pals-ple/" rel=3D"no=
referrer" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-pal=
s-ple/</a><br>
<br>
<br>
<br>
----------------------------------------------------------------------<br>
DISCUSS:<br>
----------------------------------------------------------------------<br>
<br>
Thank you for the work on this document.<br>
<br>
Please let me know if the working group has already had a discussion on the=
<br>
following references, it is entirely possible that this was discussed and<b=
r>
agreed upon, in which case thank you for letting me know and pointing me to=
 the<br>
discussion.<br>
<br>
I believe the following references should be normative instead of informati=
ve.<br>
- RFC 3985 (which is informational, so if we agree the IESG also has to app=
rove<br>
the downref that hasn&#39;t been called out in IETF Last Call) - RFC 3550<b=
r>
<br>
<br>
----------------------------------------------------------------------<br>
COMMENT:<br>
----------------------------------------------------------------------<br>
<br>
This is non-blocking because I am not sure about the resolution. Hopefully<=
br>
discussion with the authors and the responsible AD will help.<br>
<br>
I was puzzled to see the following paragraph in Section 7.2.2:<br>
<br>
&gt; The recovered clock MUST comply with the jitter and wander requirement=
s<br>
applicable to the type of attachment circuit, specified in: &gt; &gt; [G.82=
5] and<br>
[G.823] for SDH &gt; &gt; [GR253] for SONET &gt; &gt; [G.8261] for synchron=
ous Ethernet &gt; &gt;<br>
[G.8251] for OTN<br>
<br>
and at the same time all of these references are informative. I understand =
that<br>
depending on which of these you are considering, the others might be<br>
unnecessary to read, however with the requirement text I still feel those w=
ould<br>
have made more sense as normative references.<br>
<br>
Note that a similar comment could be made for the following text in Section=
<br>
3.2, motivating the need for [G.8262] and [G.8261.1] being normative:<br>
<br>
&gt; While using external timing inputs (aka BITS [ATIS-0900105.09.2013]) o=
r<br>
synchronous Ethernet as defined in [G.8261] the characteristics and limits<=
br>
defined in [G.8262] have to be considered. &gt; &gt; While relying on preci=
sion time<br>
protocol (PTP) as defined in [G.8265.1], the network limits defined in<br>
[G.8261.1] have to be considered.<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000aba33906286ff7b7--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls
aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBhbHMtbGVhdmVAaWV0Zi5vcmcK

--===============3845233022833397472==--