Re: [tcpm] John Scudder's No Objection on draft-ietf-tcpm-yang-tcp-07: (with COMMENT)

["Scharf, Michael" <[e-mail]>]

Hi John,

Thanks a lot for these minor comments.

For the sake of completeness, please find below an explanation how the new version -08 has been updated (cf. https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-08).

> -----Original Message-----
> From: John Scudder via Datatracker <[e-mail]>
> Sent: Wednesday, June 29, 2022 8:30 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: John Scudder's No Objection on draft-ietf-tcpm-yang-tcp-07: (with
> COMMENT)
> 
> John Scudder has entered the following ballot position for
> draft-ietf-tcpm-yang-tcp-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this document. I have two minor comments.
> 
> 1. In §1,
> 
>    *  TCP-AO and TCP MD5 configuration for Layer 3 VPNs is modeled in A
>       Layer 3 VPN Network YANG Model [RFC9182].  This model assumes that
>       TCP-AO specific parameters are preconfigured in addition to the
>       keychain parameters.
> 
> When you say "this model" are you referring to RFC 9182, or the present
> document? You could clarify by saying "that model" if you're talking about
> 9182
> (which I think is the case?), or "the present document" if you mean your own
> spec.

"This" here refers to RFC9182. We are not sure whether there is really an ambiguity in this case, given that the RFC is just cited before this word. Note that I am not a native speaker. For the time being, we left this wording as is. I guess the RFC editor will anyway look at that.

> 2. In §6, perhaps consider using a different term for an on-path attacker
> other
> than "MITM", which conventionally (to my knowledge) expands to "man in
> the
> middle". (Or I think you could just drop "e.g. MITM", which doesn't seem to
> add
> much.)

Indeed. We have just dropped "e.g. MITM".

Thanks

Michael