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

["Peterson, Jon" <[e-mail]>]

Thanks for the notes Russ. Some responses inline.
    
    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.

PASSporT Type ("ppt") is defined in RFC8224 Section 4. Its use is consistent with the terminology in the IANA Considerations of RFC8225 (Section 11.4) which formally names that registry the "PASSporT Extensions Registry." I'll clarify that we mean this registry in the IANA Considerations of the stir-passport-divert spec (and add the URL of the registry as you suggest below), but I think it's okay if we keep using the terminology "PASSporT Type".
    
    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.

No problem, will add that.
    
    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.  

Well, the "header" and "claims" terminology is from the JWT RFC (7519), "payload" comes from the core JWS RFC (7515). They are kind of used interchangeably around the STIR specs; there are plenty of references to claims in RFC8225. I think I'm okay with continuing to use "payload" and "claims" to mean the same thing.

    Similarly, the last paragraph should say
    that the PASSporT Payload of a "div" PASSporT MUST NOT contain an
    "opt" claim.

Probably that's fine. I'm idly wondering if some other PASSporT extension might want to use "opt" in conjunction with "div" for some reason. Seems unlikely, and we could just leave it to any future extension to patch this later if needed.
        
    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.

"as the authentication service sees it" there is not about visibility, it's referring to the fact that the intended recipient may change in flight - the authentication service sees it before those changes.
    
    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.
    
Will do.

    Examples of "x5u" claims use the .pkx file extension.  Please use .cer
    to align with the conventions in RFC 2585.
    
Will do. And will do those nits below, with my one note there...
    
    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 ..."

I thought we weren't supposed to put references in the abstract (apart from notes about RFC obsoleted etc. by this spec).
    
    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.
    
Jon Peterson
Neustar, Inc.