[I2nsf] Erik Kline's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS and COMMENT)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

 general ]

* Similar to df-bit and ecn, should there be a tunnel-grouping leaf that
  controls how inner DSCP marking should be reflected on the outer IPsec
  header? (RFC 2983 suggests using multiple tunnels instead and warns about
  the danger of packet reordering as a result of variable DSCP marking (as
  well as the potential information leak as a security issue), so maybe this
  isn't important.

  Separately, what about a setting to explicitly configure the DSCP mark on
  the outer header for all encap'd packets?

[ appendix A ]

* I'm unclear on what bypass-dscp=true means.  Does it mean that the DSCP
  value is *not* part of the traffic selector?

  Should this instead be called "ignore-dscp" or "skip-dscp"?

* Related: does the dscp-mapping leaf only have significance if bypass-dscp
  is false?  If so, is there some "must ../bypass-dscp ..." syntax that would
  be applicable?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ appendix A ]

* WRT the df-bit description.  I think something should say that this
  MUST be ignored or has no meaning when the local/remote IP addresses
  are IPv6 addresses.

[ appendix D ]

* "2001:DB8" -> "2001:db8" everywhere

  RFC 5952 section 4.3 says: lowercase for hex characters.

[ appendix E ]

* "2001:DB8" -> "2001:db8" everywhere

  RFC 5952 section 4.3 says: lowercase for hex characters.


[[ questions ]]

[ section 6.2 ]

* Why is spd-mask a hex-string when spd-mark is a uint32?  I would have
  expected them both to be uint32 or, at a minimum, both the same type.

  In appendix A they both appear to be uint32.


[[ nits ]]

[ section 1 ]

* Saying that SDN allows "users to directly program..." seemed a little odd
  (vis. common definitions of "users").  Perhaps s/users/administrators/, or
  "network operators"?  Alternatively "allows I2NSF Users", perhaps.

[ section 6.2 ]

* s/Notificsation/Notification/

* s/conform/constitute/g?

[ appendix A ]

* "NOT ESP encapsulation." -> "NO ESP encapsulation.", perhaps

[ appendix B ]

* s/typedef pfs-group{/typedef pfs-group {/

* s/the only defined right now/the only one defined right now/

* In the description for pad/identity/ipv4-address:

  "Specifies the identity as a single four (4) octet." ->
  "Specifies the identity as a single four (4) octet IPv4 address."