Re: [ippm] Intdir telechat review of draft-ietf-ippm-rfc8321bis-02

[Timothy Winters <[e-mail]>]

On Fri, Jul 15, 2022 at 12:52 PM Giuseppe Fioccola <
[e-mail]> 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 <[e-mail]>
> Sent: Friday, July 15, 2022 3:53 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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
>
>
>