Editorial Issues (from J. Arkko's mail)

[luigi@…]

Issue raised by J. Arkko in: ​http://www.ietf.org/mail-archive/web/lisp/current/msg02001.html

Editorial:

The document would benefit from a more systematic description of what the different message types, encapsulation modes, and src/dst addresses are. I had trouble following what addresses each message has in all cases, for instance.

EID-to-RLOC mapping as that would introduce a circular dependancy.

dependency...

in a caching mode, where it saves information about oustanding Map-

outstanding...

Encapsulated Map-Reqeust to a matching ETR. It does not otherwise
Reqeusts, originates new Map-Requests to the correct ETR(s), accepts

Request...

ETR, though static configuration or another out-of-band mechanism

through

authoratative

authoritative?

Encapsulated Map-Request: a LISP Map-Request with an additional
LISP header prepended. Sent to UDP destination port 4342. The
"outer" addresses are globally-routeable IP addresses, also known
as RLOCs. Used by an ITR when sending to a Map-Resolver and by a
Map-Server when sending to an ETR.

... when forwarding a MAP-Request to an ETR?

provides better information about the set
of define EID prefixes.

... defined EID ...

RFC 2402 is a normative reference, but not used anywhere.

[luigi@…]

Reply sent by Vince Fuller:

• The first point in this issue is more a comment on style rather than substance; the LISP document authors explicitly decided to put all of the message definitions in the base protocol document (draft-ietf-lisp) rather than to scatter them in the different subsystem documents. I thought that all of the typos and other editorial nits had been fixed in the -07 document but see that some remain; I'll fix those for -08.

Note: ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated.

[luigi@…]

The WG Chairs will wait for the -08 version of the draft before taking a final decision on this issue.