Subject: Re: [Srcomp] review of 00-07

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 11 Nov 2020 13:46:48 +0000

Darren inline with WH>

I am ok with all of the changes suggested.

From: Srcomp <[email-masked]> on behalf of "Darren Dukes (ddukes)" <ddukes=[email-masked]>
Date: Wednesday, 11 November 2020 at 07:49
To: "[email-masked]" <[email-masked]>
Subject: [Srcomp] review of 00-07

I have a few minor issues we could address in 01 or wait until 02.

- Section title capitalization nit
First word capitalized or every word? RFC8402 capitalizes every word, we should stick with that style.

-1 Introduction nit
The latter part of the introduction no longer flows well. we could change it...
<OLD>
It is a goal of the design team to identify the solutions to SR over IPv6 SID list compression.

In each category, the requirements are described under several sub-categories including

   o  Efficiency and performance

   o  Functional requirements

   o  Operational requirements

   o  Scalability requirements

   o  Convergence requirements

   o  Security requirements

For each requirement, a description, rationale and metrics are described.

The design team will produce a separate document to analyze the proposals.

</OLD>
<NEW>
It is a goal of the design team to identify the requirements for proposals to SR over IPv6 SID list compression.

For each requirement, a description, rationale, and metrics are defined.

The design team will produce a separate document to analyze the proposals.

<NEW>

WH> ok for me

- 2.1 Requirements Language nit
Should we delete this section?  Does it belong in an informational draft?  I didn't think so but requirements drafts don't seem to be consistent.
Should we change SHOULD/MUST/MAY to should/must/may?

WH> I would use capital representation

- 2.2 Terminology section should include a definition of Metric, some metrics are measurements, some are binary yes/no
<NEW>
Metric: measurement of aspects of a compression proposal to determine the extent to which it meets a requirement.  It may or may not provide a binary determination.
</NEW>

WH> ok for me

- 3.1.1 SRv6 Encapsulation Header
We should include this in terminology 2.2:
<NEW>
SRv6 Encapsulation Header: The IPv6 header, and any extension headers preceding a payload, used to implement a Base SRv6 or compression proposal.
</NEW>

WH> ok for me

- We use compression solution, compression method, compression mechanism, compression proposal interchangeably.
We should choose one if possible, how about compression proposal?

WH> compression proposal is good for me

- 3.1.2 we don't mention where parsing starts
<OLD>
D.PRS(segment list): number of headers parsed during processing of the segment list.
</OLD>
<NEW>
D.PRS(segment list): number of headers parsed during processing of the segment list, starting from and including the IPv6 header.
</NEW>

WH> ok for me

- 3.1.3 s/statestored/state stored/

WH> ok

- 4.2.1 "in the same way" was not clear, perhaps "with the same path" is better.
<OLD>
A compressed solution needs to support the objectives in the same way
</OLD>
<NEW>
A compression proposal needs to support the objectives with the same path.
</NEW>

WH> ok with me

- 5.1 missing a word...
<OLD>
Does not require removal of existing IPv6 planning
</OLD>
<NEW>
Does not require removal of existing IPv6 address planning
</NEW>

WH> ok

- appendix s/128bit/128-bit/

WH> ok

Darren