[stir] WG Last Call Comments: draft-ietf-stir-passport-divert-05

[Russ Housley <[e-mail]>]

Document: draft-ietf-stir-passport-divert-05
Reviewer: Russ Housley
Review Date: 2019-04-15

Major:

Section 1: The last paragraph introduces the "div" PASSporT type.  In
another document, IANA got confused when the "type" was not aligned with
the names used for the registries.  Looking at the structure of RFC 8225,
I think that "div" is a PASSporT Header Parameter value.  Please reword
to provide clarity.  Also, later in the document, "div" PASSporT is used
as shorthand.  This seems very useful.  I suggest this be defined in
Section 1 and used consistently in the document.

Section 1: Please provide similar clarity for the separate "div-o"
PASSporT type and "opt" PASSporT element.  Defining a "div-o" PASSporT
in Section 1 would also help the reader.

Section 3: The first paragraph points out that a new PASSporT is only
necessary when the canonical form of the "dest" identifier (per the
canonicalization procedures in [RFC8224] Section 8).  This seems like
a place for a MUST NOT statement.  If the canonical form of the "dest"
identifier is unchanged, then a new PASSporT with a "div" claim MUST
NOT be produced.

Section 3: The text talks about the PASSporT claims object.  I think
this is the PASSporT Payload as described in Section 5 of RFC 8225.
Please use the same terms.  Similarly, the last paragraph should say
that the PASSporT Payload of a "div" PASSporT MUST NOT contain an
"opt" claim.

Section 5: This section also text talks about the PASSporT claims object.
As above, I think this is the PASSporT Payload as described in Section 5
of RFC 8225.

Section 10: As I said above, in another document, IANA got confused when
the "type" was not aligned with the names used for the registries.  This
can be avoided by providing the URL for the intended registry in each
subsection.


Minor:

Section 1: The second paragraph says: "... it also provides a signature
over the called number as the authentication service sees it."  I think
the point is to authenticate the intended recipient, not just provide
visibility.

Section 2: Please update the first paragraph to reference RFC 8174
in addition to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
   
Of course, also add a normative reference to RFC 8174.

Examples of "x5u" claims use the .pkx file extension.  Please use .cer
to align with the conventions in RFC 2585.


Nits:

The document uses 'div' and "div".  It also used 'dest' and "dest".
Please pick one convention, and then use it throughout the document.

Suggestion for the start of the Abstract: "This document extends
PASSporT, which is specified in RFC 8224 to convey cryptographically-
signed ..."

The 'Updates' line in the title page header should list only the numbers
of the to-be-updated RFCs (if approved).

Outdated reference: draft-ietf-stir-rph has been published as RFC 8443.
Please update the reference.