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

[Eric Burger <[e-mail]>]

Updates have been done. I could not tell you who did the updates because now it has been passivized ;-)

The only update not applied is that while it is best to protect the key, it really needs to be protected at rest.


> On Apr 2, 2019, at 5:39 PM, A. Jean Mahoney <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore