Re: [ippm] Shepherd Review of draft-ietf-ippm-stamp-05

[Greg Mirsky <[e-mail]>]

Dear Tal,
thank you for your thorough review and clear, to the point comments. I'll
be working on updating the draft to address your comments and will share
the proposed changes before uploading the new version of the draft.

Regards,
Greg

On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi <[e-mail]>
wrote:

> Dear Authors,
>
> Having reviewed the document, I found that it is clear and
> straightforward, and that it is almost ready to be submitted to the IESG,
> with a few minor comments below.
>
> I will highly appreciate if you can post an updated draft, and afterwards
> we will proceed with the publication process.
>
> Thanks,
> Tal.
>
>
> Comments:
>
> - Section 1: I would suggest to mention that TWAMP Light is a lightweight
> architecture of a TWAMP deployment that is presented in RFC 5357.
> - Section 2:
> - The term OSS/BSS should be defined.
> - The acronym SDN should be spelled out in its first appearance.
> - Section 4:
> - "Unauthenticated STAMP test packets are compatible on the wire with
> unauthenticated TWAMP-Test [RFC5357] packet formats."
>   Please explain what "compatible" means. The format defined in STAMP is
> identical to RFC 5357? Can be configured to a specific mode in which it is
> identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a STAMP
> node? You may want to add a reference here to section 4.4.
> - Section 4.1.1.:
> - Please clarify that the timestamp field is as specified in RFC 5357 and
> RFC 8186.
> - "The Reflect Octets capability defined in [RFC6038]." ==> "This field is
> used for the Reflect Octets capability defined in [RFC6038]."
> - Section 4.1.2. + 4.2.2. + 4.3:
> - Please clarify that the HMAC field is as defined in RFC 5357, and covers
> the same fields as defined in RFC 5357.
> - Section 4.2.1.:
> - "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)"
> - Section 4.3:
> - "If confidentiality protection for STAMP is required, encryption at the
> higher level MUST be used."
>   Please elaborate, preferably with an example. IPsec is at a lower layer
> than STAMP, so not sure "higher level" is clear to the reader.
> - Section 5:
> - This section should be more detailed. You may want to say that the
> general security considerations of TWAMP are discussed in RFC 5357. You may
> also want to explain that the main difference between STAMP and TWAMP is
> the control plane, and you may want to make note that STAMP configuration
> procedures should be secured in order to mitigate attacks at the control
> plane.
> - References:
> - I suggest to move "[BBF.TR-390]" to the informative references.
> - draft-ietf-ippm-port-twamp-test ==> RFC 8545.
> - Minor nit:
> - "less the length" ==> "minus the length"
>
>