Thanks for the notes Elwyn.
Summary: Essentially ready with a few minor nits except that I am not sure
whether it should state that it updates RFC 4916 in the header and may need to
be more explicit about exactly what it updates in RFC 4916. The explanations
seem sensible and are well explained but I am not a SIP guru so I am not able
to vouch for the completeness or technical accuracy of the use cases.
Historically, this document did start out updating RFC4916, but it now effectively provides an alternative that is specific to the STIR universe. I know the I-D name is misleading, but there didn’t seem to be much point in changing it as the published RFC does not contain the I-D name.
Major issues:
None
Minor issues:
s1, para 3: The document refers to superseding the guidance of RFC 4916 and
fixing the interactions with SIPBRANDY. Does this mean that thi document
should declare that it updates RFC 4916. If so, should it be more explicit
about which parts of RFC 4916 are updated and how.
See above – it doesn’t Update in the formal sense RFC4916.
Nits/editorial comments:
General: s/e.g. /e.g., / (3 places - one is an end of line)
Okay.
Abstract: Add a reference to RFC 8224 which features the introduction of the
STIR framework, updating SIP Identity and possibly to RFC 4474 that originally
introduced SIP Identity.
I was taught not to cite RFCs in Abstracts when I was a kid, as abstracts are supposed to be legible without relying on external references. While I understand it is now commonplace, I still don’t favor it as a style.
s1, para 1: expand vishing - vishing (voice phishing) - I think the term is not
used in RFC 7340.
Sorry, that should be a reference to RFC7375. Fixed.
s1, last para: s/This scope/The scope/
Fixed.
s3, para 2: s/various mechanisms like private ENUM [RFC6116] might be
consulted/potentially using various mechanisms such as consulting a private
ENUM [RFC6116]/
Okay.
s3, para 3: s/just like dialog-forming requests/in the same way as
dialog-forming requests/
OK.
s7, para 2: s/because the keys exchanges/because the keys exchanged/
Fixed.
s8, para 1: I think there may be a problem, with this sentence:
> Some sort of directory service might exist advertising support for
> connected identity which institutions could use to inform potential
> callers that, if connected identity is supported when reaching them
> with SIP, there is a potential security problem.
I think it is trying to say that the if a call to an identity in a location
that supports connected identity, according to the directory, doesn't respond
with appropriate connected identity type responses then the caller should be
suspicious. This may just be a missing 'not' thus:
if connected identity is NOT supported when reaching them with SIP,
Good catch, fixed.
Jon Peterson
TransUnion
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx