[sipcore] Doc Shepherd review of draft-ietf-sipcore-rejected-05

["A. Jean Mahoney" <[e-mail]>]

Hi Eric and Bhavik,

Thanks for addressing all of the feedback so far. In preparation for the 
Doc Shepherd Write-up, I have run idnits, gone through the ID Checklist, 
and made my own pass through the draft. I have the following feedback 
below (overwhelmingly nits) -

Thanks!

Jean


------------------------------------------------------------------------
Major issues:
-------------

None.


Minor issues:
-------------

The Terminology section still needs a bit of tweaking (idnits complains):

In draft:

    This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
    "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
    "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only
    when, they appear in all capitals, as shown here.


Current boilerplate:

    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.


Nits:
-----

Throughout the document, replace "Call-Info header" with "Call-Info 
header field".


1. Introduction

Expand the acronym UAC on first use.

s/Figure 1 and Figure 2 shows/Figure 1 and Figure 2 show


Current:

                The problem here is that network elements downstream
    from the intermediary might interpret the 607 as a user (human)
    marking the call as unwanted, as opposed to a statistical, machine
    learning, vulnerable to the base rate fallacy [BaseRate] algorithm
    rejecting the call.  In other words, those downstream entities should
    not be relying on another entity 'deciding' the call is unwanted.


Suggested:

                The problem here is that network elements downstream
    from the intermediary might interpret the 607 as coming from a user
    (human) that has marked the call as unwanted, as opposed to coming
    from an algorithm using statistics or machine learning to reject
    the call. An algorithm can be vulnerable to the base rate fallacy
    [BaseRate]. In other words, those downstream entities should not rely
    on another entity 'deciding' the call is unwanted.


s/SIP header passed back/Call-Info header field passed back



3.3 UAC Operation

s/feature capability tag in the INVITE request/feature capability 
indicator in the Feature-Caps header field of the INVITE request



3.4 Legacy Interoperation

Current:

    One aspect of using a feature capability is only the network elements
    that will consume (UAC) or play an announcement (media gateway, SBC,
    or proxy) need understand the sip.608 feature capability.  All other
    (existing) infrastructure can remain without modification, assuming
    they are conformant to Section 16.6 of [RFC3261], specifically they
    will pass headers such as "Feature-Capability: sip.608" unmodified.

Suggested:

    One aspect of using a feature capability is that only the network
    elements that will either consume (UAC) or play an announcement
    (media gateway, session border controller (SBC) [RFC7092], or proxy)
    need to understand the sip.608 feature capability. The rest of the
    infrastructure does not need to be modified, assuming that the other
    network elements conform to Section 16.6 of [RFC3261], specifically
    that they will pass header fields such as "Feature-Capability:
    sip.608" unmodified.



3.5 Announcement Requirements

s/that will be doing the announcement/that handles the announcement

s/the modality for conveying/how to convey



4.1 Full Exchange

In the examples, follow guidance from RFC2606, RFC3849, and RFC6890 on 
constructing example addresses, FQDNs, and TNs:
    o Replace IPv4 addresses with addresses in the example space
      [RFC6890]: 192.0.2.0/24
      Or better yet, use IPv6 examples [RFC3849]: 2001:DB8::/32
    o Use example FQDNs specified in [RFC2606].
    o Use example phone numbers in the following space:
      +1<area code>555<0100-0199>


s/exemplary purposes/example purposes

s/at rest/at best



5.4. Call-Info Purpose

Current:

    This
    modifies the registry header field parameters and parameter values by
    adding this RFC as a reference to the line for the header field
    "Call-Info" and parameter name "purpose":

Suggested:

    This
    modifies the "Header Field Parameters and Parameter Values"
    subregistry of the "Session Initiation Protocol (SIP) Parameters"
    registry by adding this RFC as a reference to the line for the
    header field "Call-Info" and parameter name "purpose":



6. Security Considerations

Current:

    Another risk is for an attacker to purposely not include the sip.608
    feature capability in a flood of INVITE requests, direct those
    requests to proxies known to insert the sip.608 feature, and direct
    the SDP to a victim device.

Suggested:

    Another risk is for an attacker to flood a proxy that supports the
    sip.608 feature with INVITE requests that lack the sip.608 feature
    capability in order to direct the SDP to a victim's device.

s/pharming/phishing    (For more info on this edit, see RFC4949)

s/lookup/look up

s/dialled/dialed

s/jourisdiction's/jurisdiction's



8.3 Informative References

[BaseRate] s/ http://www.dtic.mil/get-tr-doc/pdf?AD=ADA045772 /
               https://apps.dtic.mil/docs/citations/ADA045772