Subject: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-locparam-05: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 04 Feb 2020 22:38:23 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-sipcore-locparam-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-locparam/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Ben’s comments, and have only some editorial ones of my own to add:

— Section 4 —

   Only a fully qualified host name is valid.  The syntax does not
   support IP addresses, and if an entity conforming to this
   specification receives a Geolocation header field with a "loc-src"
   parameter containing an IP address then the parameter MUST be
   removed.

It’s a small point, but as you’re already identifying a subject (“an entity
conforming to this specification”), it’s unnecessarily awkward to use oassive
voice:

NEW
   Only a fully qualified host name is valid.  The syntax does not
   support IP addresses, and if an entity conforming to this
   specification receives a Geolocation header field with a "loc-src"
   parameter containing an IP address, it MUST remove the
   parameter.
END

— Section 7 —

   This document introduces the ability of a SIP intermediary to insert
   a host name indicating that they added the specific locationValue to
   the Geolocation header field.

Make it “indicating that it added”; there aren’t multiple intermediaries here.

   If such trust domain is not given, it is
   strongly recommended to delete the location information.

I think the right fix to Ben’s comment here is “If a sufficient trust
relationship does not exist, it is strongly recommended that the location
information be deleted.”

---

From: <[email-masked]>
Date: Mon, 10 Feb 2020 09:27:26 +0000

Hi,
Thank you for your comments.
I have incorporated your proposals as below mentioned.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Barry Leiba via Datatracker <[email-masked]> 
Gesendet: Mittwoch, 5. Februar 2020 07:38
An: The IESG <[email-masked]>
Cc: [email-masked]; Jean Mahoney <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Betreff: Barry Leiba's No Objection on draft-ietf-sipcore-locparam-05: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

— Section 4 —

It’s a small point, but as you’re already identifying a subject (“an entity conforming to this specification”), it’s unnecessarily awkward to use oassive
voice:

NEW

[RJ] OK, have it changed to your proposal.

— Section 7 —

I think the right fix to Ben’s comment here is “If a sufficient trust relationship does not exist, it is strongly recommended that the location information be deleted.”

[RJ] OK. With regard to Ben's comment I have changed it to:
To avoid problems with misinterpretation of the
    "loc-src" parameter, the value should be removed when passed to another domain.

Seeing your proposal I would change the sentence now to:

To avoid problems of a possible corruption of the location information including the "loc-src" parameter when using a untrusted relationship, it is strongly recommended to delete location information when passed to another domain out of the trust domain.

I hope this is OK for you.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Feb 2020 08:46:19 -0500

Thanks, Roland, for the response and for addressing my comments.  It
all looks good.

Barry