Re: [Tsv-art] Tsvart last call review of draft-ietf-mpls-rfc6374-sfl-08

[Stewart Bryant <[e-mail]>]

Mirja, thank you for your review.

I have actioned the comments as described below and they are all in the markdown ready for compile and upload when I have addressed the other review comments.

> On 25 Jan 2021, at 14:07, Mirja Kühlewind via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Mirja Kühlewind
> Review result: On the Right Track
> 
> E.g. section 7 contains the following text:
> 
> "A number of methods are described.  The expectation is that the MPLS
>   WG possibly with the assistance of the IPPM WG will select one or
>   maybe more than one of these methods for standardization."
> 
> Is the plan still to select one? If not, why are these different formats needed?

I have changed the text as follows:

A number of methods are described. Each of these methods has different
characteristics and different processing demands on the packet forwader.
The choice of method will depend on the type of diagnostic that the operator seeks. 


> 
> Also there is this editorial note in Sec 9.1:
> 
> "Editor's Note we need to review the following in the light of further
>   thoughts on the associated signaling protocol(s).  I am fairly
>   confident that we need all the fields other than SFL Batch and SFL
>   Index.  The Index is useful in order to map between the label and
>   information associated with the FEC.  The batch is part of the
>   lifetime management process."

That a comment from an old discussion. I have moved the text.

> 
> And in this context also the purpose of section 10 is unclear to me:
> 
> "A future version of the this document will discuss the applicability
>   of the various methods to pro-active and on-demand Measurement."

Again an old comment. I have removed the text.

> 
> One procedural comment: I had to take a look at draft-ietf-mpls-sfl-framework
> to look up the concept of SFL which suggests to me that this document should
> probably be a normative reference.

That was because the framework was originally Informational and we want to
Avoid the downref. It is now published as an ST RFC so have moved the ref to normative,

> 
> Now regarding RFC8321: The marking scheme shown in section 5 seems to assume a
> RFC832-like marking. RFC8321 is mentioned (only) in section 8, however, the
> discussion there is rather unclear to me. To me it seem that RFC8321 marking is
> assumed and as such this should be stated clearly in the introduction,
> potentially with a normative reference to RFC8321.

It says in the introduction 

"An approach to mitigating these synchronization issue is described in
{{RFC8321}} in which packets are
batched by the sender and each batch is marked in some way such that
adjacent batches can be easily recognized by the receiver.”<

> 
> Some nits:
> - Sec 5: "acting as proxy data service packets

Done

> Section 4" -> ... as described
> in Section 4...? -

I have checked each of the references and I think a pointer to the parent section is fine.

> Sec 5: "This it is proposed" -> "Thus it is proposed”

Done

> - Sec
> 5: "that in the time interval being analyzed, 10 packets always flow." -> Maybe
> "that 10 packets are used in each flow in the time interval being analyzed" ...?
>   packets always flow.
> 
> 
Done

- Stewart