Re: [yang-doctors] Yangdoctors early review of draft-ietf-lisp-yang-20

[Luigi Iannone <[e-mail]>]

Joe,

Thank you very much for your review.

The authors will take care of addressing your comments.

Ciao

L.


> On Nov 27, 2023, at 19:04, Joe Clarke via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Joe Clarke
> Review result: On the Right Track
> 
> 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.
> 
>