[Taps] Roman Danyliw's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-taps-interface-22: 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/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-taps-interface/



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

** Section 6.3.  I’m having trouble understanding the level of abstraction used
to specify the SecurityParameter API if the desired outcome is an interoperable
solution.  My top-line concern is around what are the defined security
parameters are where are they formally defined. The API examples seem to
suggest they are “identity, server-certificate, client-certificate, key-pair,
supported-group, ciphersuite, signature-algorithm, and pre-shared-key.”

A few examples of this ambiguity:

-- “SecurityParameters.Set(identity, myIdentity)”: What is the “identity”
parameter? What would be passed here?

-- Per “SecurityParameters.Set(server-certificate, myCertificate)” and
“SecurityParameters.Set(client-certificate, myCertificate)”, assuming
myCertificate is an X.509 certificate, what format would that be passed in
(e.g., PEM, DER)?

-- What is in “myCertficate”:
o can it be a certificate chain?
o in the case of client-auth or a server, is this a bundle with both an X.509
and a private key?

-- The parameters “supported-group”, “ciphersuite” and “signature-algorithm”
all appear to be enumerated values.  Where do those come from?


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

Thank you to Sean Turner for the SECDIR review.

** Section 6.1.
-- Per “Port (a 16-bit integer):”, shouldn’t this be “16-bit unsigned integer”?

-- Per “Service (an identifier that maps to a port; either the name of a
well-known service, or a DNS SRV service name to be resolved):”, what makes
something a “well-known service”?  Is this string have to be from
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?

-- Per “IP address (IPv4 or IPv6 address):”, is there a formal syntax for an
IPv4 or IPv6 address that can be cited?

** Section 6.3.  Editorial.  Should the convention of “myVariableName” be used
here? OLD SecurityParameters.Set(pre-shared-key, key, identity)

NEW
SecurityParameters.Set(pre-shared-key, myKey, myIdentity)

** Section 6 of draft-ietf-taps-arch-18 said:
==[ snip ]==
   However, a Transport
   Services implementation can race different security protocols, e.g.,
   if the application explicitly specifies that it considers them
   equivalent.
==[ snip ]==

How does one use the API described in this document to convey equivalence?

** A few methods seem to be used in the prose without formal definition beyond
the example:

-- Section 6.1.1: WithTTL()
-- Section 6.1.3: WithProtocol()