Subject: [Last-Call] Genart last call review of draft-ietf-sipcore-locparam-04

From: Ines Robles via Datatracker <[email-masked]>
Date: Sun, 26 Jan 2020 14:28:53 -0800

Reviewer: Ines Robles
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sipcore-locparam-04
Reviewer: Ines Robles
Review Date: 2020-01-26
IETF LC End Date: 2020-01-27
IESG Telechat date: Not scheduled for a telechat

Summary:

This document proposes for SIP protocol, a new geolocation parameter, the
location-source ("loc-src"), so that an entity adding the locationValue to
Geolocation header field can identify itself using its hostname.

The document does not present major issues. I have some minor
questions/suggestions at the end.

Major issues: Not found

Minor issues: Not found

Nits/editorial comments:

Section 4: "A UA MUST..." it would be nice to expand UA "A User Agent (UA)
MUST..."

Questions/Suggestions:

1- Section 1: I think it would be nice to add explicitly "This document updates
6442 by extending the Geolocation header field..."

2- Section 3:  where it states "There are various architectures defined
f...Each has it own characteristics with corresponding pros and cons...." I
think it would be nice to add a reference/s to it.

3- Which Geolocation-Error codes correspond to the situation when the "loc-scr"
field presents some error, or one LocationValue presents two "loc-src" fields
and the locationValue in both cases is correct?

Thank you for this document,

Ines.

---

From: <[email-masked]>
Date: Wed, 29 Jan 2020 06:50:57 +0000

Hi Ines,
Thank you for your review.
I have incoperated your comments within the draft.

On Question 1 In Section 1 I have changed the last paragraph by adding the reference of RF64412 as follows:
 " This document extends the Geolocation header field of RFC6442, by allowing an entity adding the locationValue to identity itself using a hostname. This is done by defining a new geoloc-param header field parameter,

Hope this is OK for you.

Question 2: It is difficult to reference the various architectures for emergency since each country, based on national regulation rules, may have it's own architecture. 

Question 3: This apply to the rules defined in RFC6442 in Section 4.4.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ines Robles via Datatracker <[email-masked]> 
Gesendet: Sonntag, 26. Januar 2020 23:29
An: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Genart last call review of draft-ietf-sipcore-locparam-04

Reviewer: Ines Robles

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

Summary:

This document proposes for SIP protocol, a new geolocation parameter, the location-source ("loc-src"), so that an entity adding the locationValue to Geolocation header field can identify itself using its hostname.

The document does not present major issues. I have some minor questions/suggestions at the end.

Major issues: Not found

Minor issues: Not found

Nits/editorial comments:

Section 4: "A UA MUST..." it would be nice to expand UA "A User Agent (UA) MUST..."

Questions/Suggestions:

2- Section 3:  where it states "There are various architectures defined f...Each has it own characteristics with corresponding pros and cons...." I think it would be nice to add a reference/s to it.

3- Which Geolocation-Error codes correspond to the situation when the "loc-scr"
field presents some error, or one LocationValue presents two "loc-src" fields and the locationValue in both cases is correct?

Ines.

---

From: Ines Robles <[email-masked]>
Date: Thu, 30 Jan 2020 00:25:55 +0200

Hi Roland,

Thank you for addressing my comments. I agree with them.

Best,

Ines.

On Wed, Jan 29, 2020 at 8:50 AM <[email-masked]> wrote:

>  " This document extends the Geolocation header field of RFC6442, by
> allowing an entity adding the locationValue to identity itself using a
> hostname. This is done by defining a new geoloc-param header field
> parameter,
>
> Hope this is OK for you.
>
> Question 2: It is difficult to reference the various architectures for
> emergency since each country, based on national regulation rules, may have
> it's own architecture.
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
>
> field presents some error, or one LocationValue presents two "loc-src"
> fields and the locationValue in both cases is correct?
>