On Fri, Jul 15, 2022 at 12:52 PM Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx> wrote:
Hi Timothy,
Thank you for the review.
Please see my replies inline tagged as [GF].
I will address your comments in the next version.
Best Regards,
Giuseppe
-----Original Message-----
From: Timothy Winters via Datatracker <noreply@xxxxxxxx>
Sent: Friday, July 15, 2022 3:53 PM
To: int-dir@xxxxxxxx
Cc: draft-ietf-ippm-rfc8321bis.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx
Subject: Intdir telechat review of draft-ietf-ippm-rfc8321bis-02
Reviewer: Timothy Winters
Review result: Not Ready
draft-ietf-ippm-rfc8321bis-02
I am an assigned INT directorate reviewer for draft-ietf-ippm-rfc8321bis-02.
These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.
Based on my review, if I was on the IESG I would ballot this document as DISCUSS.
DISCUSS:
Section 3.1
This section states two possible methods using either a fixed number of packets or fixed timer. Only fixed timer is defined in draft. I would think that supporting the fixed timer method would be a MUST for implementations of this document.
[GF]: Ok, I can revise the statement here to highlight that the fixed timer method is a MUST for the scope of this document.
[TW] - That works for me.
Section 3.2
Suggest a lower case must for clock network synch. I would suggest using a
capital MUST, if the clocks aren't in synch this method will not work properly.
Additionally, I was surprised there are no suggesting on what to use to keep the clocks in synch (NTP, PTP) or precision suggested in time keeping mechanism. These methods are referenced in Section 7 but I think it would make sense to give people the options in this section.
[GF]: Yes I can use a capital MUST for this sentence and adding a reference to section 5, where the timing aspect are further detailed. Note that the synchronization capability (NTP, PTP) is also mentioned in section 4.3. I may also mention it in section 3.2 or section 5.
[TW] - That works for me.
Section 7.1
While is says recommended to be a controlled domain, it should document what happens if it leaves the controlled and how to protect the borders of the domain.
[GF]: I will add more details as per draft-ietf-6man-ipv6-alt-mark.
For example, below are some considerations that can be included:
A limited administrative domain provides the network administrator with the means to select, monitor and control the access to the network, making it a trusted domain. In this regard it is expected to enforce policies at the domain boundaries to filter both external marked packets entering the domain and internal marked packets leaving the domain. Therefore, the trusted domain is unlikely subject to hijacking of packets since marked packets are processed and used only within the controlled domain.
The application to a controlled domain ensures the control over the packets entering and leaving the domain, but despite that, leakages may happen for different reasons, such as a failure or a fault. In this case, nodes outside the domain are expected to ignore marked packets since they are not configured to handle it and should not process it.
[TW] - This was the biggest issue and it looks like you are working to address it, I look forward to the next revision.
NIT:
OLD:
As discussed in the previous section, a simple way to create the
blocks is to "color" the traffic (two colors are sufficient), so that
packets belonging to different consecutive blocks will have different
colors."
New:
As discussed in the previous section, a simple way to create the
blocks is to "color" the traffic (two colors are sufficient), so that
packets belonging to alternate consecutive blocks will have different
colors.
[GF]: Ok
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
