Last Call Review of draft-ietf-sfc-nsh-integrity-05
review-ietf-sfc-nsh-integrity-05-opsdir-lc-schoenwaelder-2021-06-25-00

The document is very well written and organized, thanks for that. I
have some comments and a few nits. The issues I have a minor, I think
the document overall is in a good shape.

- From an operational perspective, I very much appreciate that there
  is some text discussing error and failure reporting and that there
  are some MTU configuration guidelines.

- The document claims:

    As depicted in Table 1, SFFs are not involved in data encryption.
    This document enforces this design approach by encrypting Context
    Headers with keys that are not supplied to SFFs, thus enforcing this
    limitation by protocol (rather than requirements language).

  I am a bit puzzled about this statement since a protocol definition
  at the end is just some form of requirements language. Well, putting
  that remark aside, I do not really see anything in the specification
  that ensures that SFFs won't get the keys. We also read:

    [...] Encryption keying material is only provided to
    these SFC data plane elements.

  Well, the specification is actually silent about how keys are
  distributed. Section 4.4. says:

    The procedure for the allocation/provisioning of secret keys (K) and
    authenticated encryption algorithm or MAC_KEY and HMAC algorithm is
    outside the scope of this specification.  As such, this specification
    does not mandate the support of any specific mechanism.

  To me, it seems the claims made in section 4.4. do not really hold.

- In section 6, you picked as the epoch 1970-01-01T00:00Z while NTP
  uses the epoch 1900-01-01T00:00Z. This leads to rollovers in the
  year 2106 for your timestamps while the NTP rollover would be in
  2036. Given that you use an NTP compatible format and a different
  epoch, I think this deserves to be spelled out explicitly so that
  people understand that they have to do conversions.

  (Alternatively, you could adopt the epoch NTP is using and the need
  for conversions goes away at the price of an earlier rollover.)

  Anyway, what I am saying is that if you pick a different epoch, I
  suggest to spell this out explicitly and to not rely on
  implementers to discover this.

Minor nits:

- In section 5.2, it should say:

  OLD

  In reference to Figure 5

  NEW

  In reference to Figure 7

- In section 7.3, I suggest this change to make it clear again to the
  reader what K is:

  OLD

  Using K and

  NEW

  Using the secret key K and