[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13,RFC 1034<http://tools.ietf.org/html/rfc1034>, November
1987.
If you look at the way this is referenced from the text, it is clear that this
should be a non-normative reference.
The host obtains
a destination EID the same way it obtains an destination address
today, for example through a Domain Name System (DNS) [RFC1034]
lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Same as above.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)",RFC
2784<http://tools.ietf.org/html/rfc2784>,
March 2000.
If you look at the way this is referenced from the text, I think this should be
a non-normative reference.
o On an ITR, prepending a new IP header consists of adding more
bytes to a MAC rewrite string and prepending the string as part of
the outgoing encapsulation procedure. Routers that support GRE
tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
support this action.
GRE is here use as an example, not as normative behavior.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds",RFC 3056<http://tools.ietf.org/html/rfc3056>,
February 2001.
Same as above.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6",RFC
4866<http://tools.ietf.org/html/rfc4866>, May 2007.
I think this one can be non-normative or even be removed, depending on how the
mobility section rewrite goes.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing",RFC
4984<http://tools.ietf.org/html/rfc4984>,
September 2007.
Background. Non-normative.
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS
http://www.iana.org/assignments/address-family-numbers.
[AFI-REGISTRY]
IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBER registryhttp://www.iana.org/assignments/
address-family-numbers/
address-family-numbers.xml#address-family-numbers-1.
Is there really no better reference for this, an RFC perhaps?
I wish there were... and that RFC could be put in to the normative-reference
section. If there is no suitable RFC I'm fine with the current two references
as-is.
[INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02.txt<http://tools.ietf.org/html/draft-ietf-lisp-interworking-02.txt>
(work in progress).
I think this one should be normative. This is such a key piece of work to
understanding Lisp, and the text seems to treat it as if it is a normative
part. For instance:
Proxy ITR (PITR): A PITR is also known as a PTR is defined and
described in [INTERWORK], a PITR acts like an ITR but does so on
behalf of non-LISP sites which send packets to destinations at
LISP sites.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-09.txt<http://tools.ietf.org/html/draft-ietf-lisp-ms-09.txt>
(work in progress).
Isn't this normative as well? Here's an example of how the text refers to it:
Map-Requests can also be LISP encapsulated using UDP destination port
4342 with a LISP type value set to "Encapsulated Control Message",
when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are
LISP encapsulated the same way from a Map-Server to an ETR. Details
on encapsulated Map-Requests and Map-Resolvers can be found in
[LISP-MS].
