[lisp] Re: Document shepherd review comments of draft-ietf-lisp-geo-07

[Dino Farinacci <[e-mail]>]

> Dear author(s), chairs
> 
> I have reviewed the document and do not find significant concerns. It is concise and well written; Please find my comments below, hopefully they will help improve the document.
> 
> Comments are separated by "----". I have provided section and context before the COMMENT (sorry, about not including the line numbers).
> Thanks,
> Kiran

Thanks for your comments Kiran. I will submit -08 on Saturday. See my responses inline to your comments.

> Abstract
> 
>    This document describes how Geo-Coordinates can be used in the LISP
>    Architecture and Protocols.  The functionality proposes a new LCAF
>    encoding for such Geo-Coordinates, which is compatible with the GPS
>    encodings used by other routing protocols.
> COMMENT
> Please expand LCAF, GPS or rephrase to avoid too many acronyms in the abstract
> ----

Done.

> 
> 1. Introduction
>     This document proposes a new LCAF encoding for Geo-Coordinates, which
>  is compatible with the one used in other routing protocols, namely
>    OSPF [I-D.acee-ospf-geo-location], IS-IS
>    [I-D.shen-isis-geo-coordinates], and BGP
>   [I-D.chen-idr-geo-coordinates] protocols.
> 
> COMMENT: 
> These documents have not progressed; I am wondering if it is possible to lower the emphasis on them
>  and rationalize other reasons to introduce new type. I think location with radius is one.
> ----

There is no emphasis on them. They are independent designs and the authors of all the documents, including this one agreed to have a consistent format for ease of implementations.

> 
> 3.  Definition of Terms
>    Geo-Point  is a Geo-Coordinate according to [GEO] that defines a
>       point from parameters Latitude, Longitude, and Altitude.
> 
> COMMENT:
> [GEO] document is not accessible, as a result, I could not verify definition of
> Geo-Point. from other sources, I read about Point is a location represented by
> Geo-Coordinates. I think this could be made clearer. Note: [GEO] is a normative
> reference so it is important to point to valid information.
> ----

I updated the URL. Good catch.

> 4.2.  Geo-Prefixes in EID-records and RLOC-records
> 
>    A Geo-Prefix is defined to be a Geo-Coordinate point and a Radius.
> 
> COMMENT:
> on the consistent usage and definition of Geo-Point.
> Geo-Coordinate point or Geo-Point with a radius. Should  it be "Radius" or "radius?
> ----

I used "Radius" when referring to Geo-Prefixes and referencing it in the packet format. I use it lower case to refer to the general term "radius".

> 
>    create connectivity to the vehicle while roaming.  This makes use of
>    predictive RLOCs that can be used when the direction of the roaming
> COMMENT:
>  please add reference to predictive RLOCs I.d
> 
> ----

Done.

> 5.  Geo-Prefix and Geo-Point Encodings
> 
>    This document has no provision to validate the Geo-Location values.
> COMMENT:
> It was not clear until now that the new LCAF type is called Geo-Location.
> Personally, I would have prefered Geo-Coordinate-v2, but if authors choose to
> use Geo-Location, please mention in Introduction that type
> 'Geo-Coordinate' is deprecated, new type called 'Geo-Location' is introduced.
> ----

The opening paragraph states the deprecation but I'll make it more clear and not the new name for the new LCAF type.

>    Reserved:  These bits are reserved.  They MUST be set to 0 when
>       sending protocol packets and MUST be ignored when receiving
>       protocol packets.
> COMMENT:
> there is no justification why reserved field is provided. It should be explained.
> 
> ----

Its there to allow expansion of the bit fields that precede it. I added text to reflect that.

> 8.  Privacy Considerations
>    *  Obfuscating a geo-point by using geo-prefixes instead uses data
>       minimization techniques.
> COMMENTS: s/geo-point/Geo-Point; s/geo-prefixes/Geo-Prefixes
> It also felt that this item is underspecified, perhaps more details or preferably an existing reference will help.
> ----

Changed.

Thanks again,
Dino