Dirk Comments (WGLC)

[boucadair]

Dear authors,
Below some nits and questions for clarification which came to me:

transport encapsulation (e.g., IPsec) only provide ... and do
=> transport encapsulations (e.g., IPsec) only provide ... and do
OR:
=> transport encapsulation (e.g., IPsec) only provides ... and does

SFFs or SFs within a Service Function Path (SFP) not authorized to access the privacy-sensitive metadata will have access to the metadata.
=> SFFs or SFs within a Service Function Path (SFP) which are not authorized to access the privacy-sensitive metadata will nevertheless per default have access to the metadata

would make it clearer at least for me ...

SFFs are entitled to modify the Base Path header => SFFs are entitled to modify the Base Header

Since Base Path Header is not defined

keying material is only provided to these SFC data elements => keying material is only provided to these SFC data plane elements.

Base Header: Provides information about the service header/ Base and Service Headers

Is it rather Service Path Header(s) what is meant here - or what is difference between Service Header and NSH??

Note: The use of AES-GCM => Note: The use of AES GCM (Advanced Encryption Standard in Galois/Counter Mode, see https://datatracker.ietf.org/doc/html/rfc7518#section-4.7)

for certain amount of time, this document uses key identifier (kid) => for certain amount of time, this document uses [RFC7635]-defined key identifier (kid)

right? Although kid is no more used in the rest of the document ...

SFC data plane elements of a lower-level domain includes the Upper- => Header processing at SFC data plane elements of a lower-level domain includes the Upper-
OR: => SFC data plane elements of a lower-level domain include the Upper-
OR: => An SFC data plane element of a lower-level domain includes the Upper-

Both Context headers have the same format as shown in Section 5.
=> Both Context headers have the same format as shown in Figure 5. ?

inner packet on which the NSH is imposed .
=> inner packet on which the NSH is imposed.

o The Additional Authenticated Data (defined in [RFC7518]) MUST be
the Service Path header, the unencrypted Context headers, and the
inner packet on which the NSH is imposed .

o Message Authentication Code covering the entire NSH data excluding
the Base header.
=>
o Message Authentication Code: is covering the entire NSH data excluding
the Base header.

The Additional Authenticated Data (defined in [RFC7518]) MUST be
the Service Path header, the unencrypted Context headers, and the
inner packet on which the NSH is imposed .

since the latter doesn't fit to top of list: 'In reference to Figure
5, the description of the fields is as
follows:'
this applies to both section 5.1 and 5.2

The Message Authentication Code (T) computation process can be illustrated as follows:
=> The computation process for the message Authentication Tag value (T) via MAC can be illustrated as follows:??

Thanks!
Best Regards
Dirk

[boucadair]

Fixed all of these in a previous revision