Subject: [sipcore] Doc Shepherd review of draft-ietf-sipcore-locparam-03

From: "A. Jean Mahoney" <[email-masked]>
Date: Sun, 6 Oct 2019 14:46:00 -0500

Hi all,

Below is my review of the version that incorporates the WGLC feedback. 
Thanks for addressing the feedback so far!

Jean

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

S4. There should be a stronger tie-in to the ABNF given in RFC6442.

Current:

    The mechanism employed adds a parameter to the location value defined
    in [RFC6442] that identifies the hostname of the entity adding the
    location value to the Geolocation header field.

Suggested:

    The mechanism adds a geoloc-param parameter to the locationValue
    defined in [RFC6442] that identifies the hostname of the entity
    adding the location value to the Geolocation header field.

To make the terminology in this draft consistent with RFC6442:
s/location value/locationValue

When referring to header field parameters, SIP specs usually use the 
token in quotes ("expires", "qop") rather than the ABNF rule name 
(c-p-expires, message-qop) in text. Also, IANA lists header field 
parameters by their tokens in the "Header Field Parameters and Parameter 
Values" sub-registry. Instead of location-source, "loc-src" should be 
used in this draft's text.

S8. The IANA Considerations section needs a bit more clarification.

Current:

    8.1. Registration of location-source parameter for Geolocation header
         field

    This document calls for IANA to register a new SIP header parameter
    as per the guidelines in [RFC3261], which will be added to header
    sub-registry under http://www.iana.org/assignments/sip-parameters.

    Header Field:  Geolocation

    Parameter Name:  loc-src

Suggested:

    8.1. Registration of "loc-src" parameter for the Geolocation header
         field

    The IANA is asked to add a new SIP header field parameter for
    the Geolocation header field in the "Header Field Parameters and
    Parameter Values" subregistry (created by [RFC3968]) of the
    "Session Initiation Protocol (SIP) Parameters" registry found at
    https://www.iana.org/assignments/sip-parameters/.

    Header Field:  Geolocation

    Parameter Name:  loc-src

    Predefined Values:  No

    Reference:  This RFC

-----
Nits:

Header:  Use just the RFC number in the Updates: field - that is, 6442.

Abstract:  Add the sentence (but not a cite, though): "This document 
updates RFC 6442."

S1.

s/edge-proxies/edge proxies

Current: ...it does not provide any indication of which
    node actually added the location value.

Suggested: ...it does not identify which node added the
    location value.

S3.

Current:

    This document makes no attempt to comment on these various
    architectures or the rationale for them wishing to include multiple
    location values.

Suggested:

    This document does not comment on these various
    architectures or on the rationale for including multiple
    location values.

s/The The/The

Current:

    The functional architecture described within ETSI [M493] is an
    example of architecture where this parameter makes sense to be used.

Suggested:

    The functional architecture described within ETSI [M493] is an
    example of an architecture where it makes sense to use this
    parameter.

S4.

s/intermediarity/intermediary (multiple instances)

S5.

s/URI the provided/URI provided

S6.

Current:

    While the addition of the location-source
    parameter does provide an indicator of the entity that added the
    location in the signaling path this provides little more exposure
    than a proxy identity being added to the record-route header field.

Suggested:

    While the addition of the "loc-src"
    parameter identifies the entity that added the location in the
    signaling path, this addition provides little more exposure
    than adding a proxy identity to the Record-Route header field.

S7.

Current:

    To avoid problems of wrong interpretation of
    loc-src the value may be removed when passed to an other domain.

Suggested:

    To avoid problems with misinterpretation of the
    "loc-src" parameter, the value may be removed when passed to an
    other domain.

S9.

s/draft The/draft. The

---

From: <[email-masked]>
Date: Mon, 7 Oct 2019 09:04:20 +0000

Hi Jean,
thank you for the review and comments.
I have them incorporated in my draft.
If nothing else needs to be done within the draft I can release the next draft version.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: A. Jean Mahoney <[email-masked]> 
Gesendet: Sonntag, 6. Oktober 2019 21:46
An: [email-masked]; SIPCORE <[email-masked]>
Betreff: Doc Shepherd review of draft-ietf-sipcore-locparam-03

Hi all,

Jean

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

Current:

Suggested:

[RJ] done

[RJ] done I changed also "location values" to "locationValues"

When referring to header field parameters, SIP specs usually use the token in quotes ("expires", "qop") rather than the ABNF rule name (c-p-expires, message-qop) in text. Also, IANA lists header field parameters by their tokens in the "Header Field Parameters and Parameter Values" sub-registry. Instead of location-source, "loc-src" should be used in this draft's text.

Current:

    Parameter Name:  loc-src

Suggested:

    Parameter Name:  loc-src

    Predefined Values:  No

    Reference:  This RFC

[RJ] done

-----
Nits:

Abstract:  Add the sentence (but not a cite, though): "This document updates RFC 6442."
[RJ] done

S1.

[RJ] done

S3.

Current:

Suggested:

[RJ] done

s/The The/The
[RJ] done

Current:

Suggested:

[RJ] done

S4.

[RJ] done

S5.

[RJ] done

S6.

Current:

Suggested:

[RJ] done

S7.

Current:

Suggested:

[RJ] done

S9.

s/draft The/draft. The

[RJ] done

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 7 Oct 2019 08:20:00 -0500

Thanks, Roland, please submit your new version.

Jean