Early Review of draft-ietf-lisp-yang-20
review-ietf-lisp-yang-20-yangdoctors-early-clarke-2023-11-27-00

Request Review of draft-ietf-lisp-yang-20
Requested revision 20 (document currently at 21)
Type Early Review
Team YANG Doctors (yangdoctors)
Deadline 2023-11-28
Requested 2023-10-11
Requested by Luigi Iannone
Authors Vina Ermagan , Alberto Rodriguez-Natal , Florin Coras , Carl Moberg , Reshad Rahman , Albert Cabellos-Aparicio , Fabio Maino
I-D last updated 2023-11-27
Completed reviews Yangdoctors Early review of -20 by Joe Clarke (diff)
Yangdoctors Early review of -11 by Christian Hopps (diff)
Comments 
Hi,

this document had already a early review by Christian Hoops, which was very helpful.
However, when authors request WGLC a couple of question were raised for which we do not know have a definite answer.

In his email (https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/) Med did raise the following two points (among others):

1   As you are using many identities that are echoing what is in https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml, I wonder whether you considered turning those into an IANA-maintained module. New identities will be added automatically to the module when, e.g., a new act is defined. FWIW, you may refer to RFC9108 or https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana-registries/.

2   You may check if the geo-coordinate grouping in https://datatracker.ietf.org/doc/rfc9179/ would be applicable here as well. If not, I would add an explanation why this isn't.

In summary:

1 Is it worth to have a IANA-maintained module?

2 Does geo-coordinate grouping apply to this document?  

Thanks in advance.

Luigi
Assignment Reviewer Joe Clarke
State Completed
Request Early review on draft-ietf-lisp-yang by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/MqYfetQ0iH3FyZ2FscWBiUwZxII
Reviewed revision 20 (document currently at 21)
Result On the Right Track
Completed 2023-11-27
review-ietf-lisp-yang-20-yangdoctors-early-clarke-2023-11-27-00
I am the latest member of YANG Doctors to review this document and the modules
therein.  I looked over chopps' previous review, and it appears most of his
comments have been addressed.  In my own reading, I found inconsistent use of
capitalization and punctuation in descriptions (e.g., some ended in periods,
some did not; most started with a capital letter, some did not); as well as
inconsistent quoting.  All modules would benefit from a `pyang -f yang`
normalization and an editorial pass.

In the ietf-lisp module itself, there are a couple of patterns in there where I
wonder if the regex is what you want exactly.  For example, is it okay if an
eid-id starts with a ':' or a '-'?  For the locator-id, this is a string of
1-64 characters, but the regex hints it could be zero or more of the character
class (a similar example exists with hop-id in address-types).

All modules' initial revisions reference the original LISP RFC but do so with a
URL only vs. a more correct, RFC 6830: ... syntax.  And speaking of revision,
most of the modules have a revision of 2021-02-22 with the exception of itr and
mapresolver.  This isn't a big deal now, as I assume you'll set all of these
when the draft is finalized.  You should also update all of the copyright years
and copyright text.

As to the two questions asked here, I can see some benefit of breaking out the
IANA parts of address-types into a module that they maintain.  But in its
current form, I don't know that it makes sense to have them maintain it.  As
for geoloc, I do see some overlap, but I am not a LISP expert at all, so I
cannot comment as to whether bringing that whole module in makes sense or would
even work with LISP implementations.  That is, it seems LISP lat and long are
expressed in degrees° minutes'seconds" whereas geoloc does this as a decimal64
from a reference frame.  I do feel that whatever direction is taken, text
explaining why geoloc is not used is useful.