Re: Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Anton Smirnov <[e-mail]>]

    Hello Dale,

    authors of the draft has just published revision -09 which addresses 
your comments. Thanks again for your comprehensive comments on the 
previous revision which certainly helped us to make the document better.

    We agree with ~90% of your comments and made relevant text changes. 
Even in those few cases were we didn't agree with comments we tried to 
alter text to make intentions and reasons more clear. So I will not 
reply here on each comment individually. Please give another round of 
review to the new revision; there should be less comments this round and 
we can have more meaningful (and faster) exchange.

---
Anton Smirnov

On Saturday 15 October 2016 03:28, Dale R. Worley wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-lisp-ddt-08
> Reviewer: Dale R. Worley
> Review Date: 2016-10-09
> IETF LC End Date: 2016-10-17
> IESG Telechat date: 2016-10-27
>
> Summary: This draft is on the right track but has open issues,
> described in the review.
>
> I believe that the technical specifics in this draft have been
> settled, but in many places the wording is unclear and contradictory
> in minor ways to the point that I was uncertain whether I understood
> what is intended.  The result is that this review is excessively long,
> as I can only point to the items that appear problematic, rather than
> pointing out the adjustments that would cure the problems.
>
> I suspect that as the design has evolved, the text has been revised
> many times, leading to incompletenesses and inconsistencies.  The
> danger, in my opinion, is that no part of the document can be reliably
> understood without correlating it with many other parts of the
> document, that many implementers will make mistakes of interpretation,
> and that there may be points on which people believe consensus was
> reached, but that their understandings of the point were contradictory.
>
> I think that the document needs a careful final editing to bring the
> terminology and all parts of the document into sync.  That will also
> reveal whether there are points on which people mistakenly believed
> there was consensus.
>
> I begin with a list of more global issues, then continue with comments
> on specific parts.
>
> * In regard to XEIDs:  The concept of XEID unifies the treatment of
> DBID, IID, AFI, and EID.  Essentially all of the processing in the
> draft is simplified by expressing processing in terms of XEIDs.  For
> instance, delegation based on DBID, IID, or AF becomes just a special
> case of delegation based on XEID-prefix.  However, it's not clear to
> me whether this concept is followed in the text.  For example:
>
> In section 3, definition "XEID-prefix" seems to assume that an
> XEID-prefix will always contain a complete DBID, IID, and AFI.
>
> In section 4.2.1:
>
>     The root DDT node is the logical "top" of the database hierarchy:
>     DBID=0, IID=0, AFI=0, EID-prefix=0/0.
>
> But really, the condition of a root node is that it's authoritative
> for the *empty* XEID-prefix.
>
> There is also the suggestion here that an AFI of 0 is somehow a
> wildcard match for any AFI value.  That is a special case that can be
> eliminated by considering the entire XEID to be prefixable.
>
> On the other hand, this text in 7.3.1 suggests that there is a "null
> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
>
>     the "referral XEID-prefix" is also initialized to the null value
>     since no referral has yet been received.
>
> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
> those need to be described in a way that doesn't leave loose ends, by
> either describing how they are expected to be used or referring to a
> document that does so.  In this document, a lot of that information is
> bundled into the definitions of "Extended EID (XEID)" and
> "XEID-prefix" in section 3.  It would be best if this information
> appeared in its own paragraphs.
>
> It appears to me that it is expected that DBID will always be zero
> (see definition "XEID-prefix"), but the machinery is defined so that
> other values can be used.
>
> IID is presumably expected to be zero except when VPNs are used.  (see
> definition "Extended EID (XEID)")
>
> Note that definition "Extended EID (XEID)" says "optionally extended
> with a non-zero Instance ID".  Read literally, that means that zero
> IIDs aren't included in the XEID, which would be insanity.  The text
> needs to clarify that IID is always present in the XEID, but is
> normally zero.
>
> AFI is taken from http://www.iana.org/numbers.html, but you have to go
> through the link to draft-ietf-lisp-lcaf to discover that; it should
> be stated in this draft.
>
> * For any given delegated prefix, there can be more than one "peer"
> DDT nodes that contain duplicated information about the prefix.  But
> the term "peer" isn't defined in the lexicon, and there is no explicit
> statement that the peers (for a prefix) must contain the same
> information.
>
> * It appears that "Map Server" has been defined elsewhere (RFC 6833),
> and that Map Servers can automatically be DDT nodes.  Or is it that
> some Map Servers are also equipped with DDT node functionality?  If
> this draft places further requirements on Map Server DDT nodes, then
> this draft should be noted as updating RFC 6833.
>
> * There seems to be two meanings of "DDT node".  One is a broad sense,
> and is any server that responds to Map-Request.  The other is a narrow
> sense, and means any DDT node in the broad sense that is not a Map
> Server, and thus is allowed to contain prefix delegations.  These
> terms need to be separated, and the uses of "DDT node" in the draft
> need to be revised to the correct term.
>
> However, the preceding paragraph assumes that a DDT node is not
> allowed to contain both prefix delegations and ETR registrations.
> That seems to be the case because in many places, those classes of
> nodes are required to behave differently (e.g., return different error
> codes for nonexistent prefixes) and be treated differently by other
> DDT nodes (e.g., referrals to them are given with different action
> codes).  But there are a few places where the text suggests that a DDT
> node could contain both prefix delegations and ETR registrations.
>
> * Is it really true that two Map Servers that are authoritative for
> the same XEID prefix can contain different sets of ETR registrations?
> That is, the DDT client (the Map Resolver) may be required to query
> the entire set of peer Map Servers to find the right ETR registration?
> Perhaps the answer is defined in the RFC describing Map Servers, but
> it affects one's understanding of this draft enough that it should be
> stated in the overview.
>
> * The role of hints is not clear.  Clearly, a DDT node can be
> configured with hints regarding some XEID-prefix, but what are the
> limitations on what RLOCs must be provided in a hint?  This seems
> especially important because it seems in practice that the
> authoritative nodes for a prefix might be reconfigured without anyone
> realizing that the hints in nodes farther down the tree need to be
> updated.  In particular, when should the DDT client follow a hint?
> Hints seem to provide the possibility of circular references.  Given
> that this is an Experimental draft, perhaps the best use of hints is
> an "open issue and consideration", and by listing it in section 11,
> these questions need not be answered now.
>
> 1.  Introduction
>
>     LISP offers a general-purpose mechanism for mapping between EIDs and
>     RLOCs.  In organizing a database of EID to RLOC mappings, this
>     specification extends the definition of the EID numbering space by
>     logically prepending and appending several fields for purposes of
>     defining the database index key: Database-ID (DBID, 16 bits),
>     Instance identifier (IID, 32-bits), Address Family Identifier (16
>     bits), and EID-prefix (variable, according to AFI value).  The
>     resulting concatenation of these fields is termed an "Extended EID
>     prefix" or XEID-prefix.
>
> This paragraph is undecided whether it is defining XEID or
> XEID-prefix.  Better, I think is to define XEID first and then define
> XEID-prefix based on that:
>
>     this
>     specification extends the definition of the EID numbering space by
>     logically concatenating several fields for purposes of
>     defining the database index key: Database-ID (DBID, 16 bits),
>     Instance identifier (IID, 32-bits), Address Family Identifier (16
>     bits), and EID (variable length, according to AFI value).  The
>     resulting concatenation of these fields is termed an "Extended EID"
>     or XEID.  Prefixes within the XEID space are thus "Extended EID
>     prefixes" or XEID-prefixes.
>
> --
>
>     It
>     also provides delegation information to Map Resolvers, which use the
>     information to locate EID-to-RLOC mappings.
>
> There needs to be clarification regarding the relationship between
> "Map Resolver" and "DDT client".  As far as I can tell, in all places
> in this document, "DDT client" is the correct term, though it is
> expected that most (but not all) DDT clients will be Map Resolvers.
> So this text should be something like
>
>     It
>     also provides delegation information to DDT clients (which are
>     usually Map Resolvers, but may be ITRs), which use the
>     information to locate EID-to-RLOC mappings.
>
> and approximately all uses of "Map Resolver" should be changed to "DDT
> client".
>
>     LISP-DDT defines a new device type, the DDT node, that is configured
>     as authoritative for one or more XEID-prefixes.
>
> Here would be a good place to lay out clearly the relationship between
> DDT node and Map Server:  whether nodes that do delegation are
> disjoint from Map Server nodes, etc.
>
> 3.  Definition of Terms
>
>     Extended EID (XEID):  a LISP EID, optionally extended with a non-
>        zero Instance ID (IID) if the EID is intended for use in a context
>        where it may not be a unique value, such as on a Virtual Private
>        Network where [RFC1918] address space is used.  See "Using
>        Virtualization and Segmentation with LISP" in [RFC6830] for more
>        discussion of Instance IDs.
>
>     XEID-prefix:  a LISP EID-prefix with 16-bit LISP-DDT DBID (provided
>        to allow the definition of multiple databases; currently always
>        zero in this version of DDT, with other values reserved for future
>        use), 32-bit IID and 16-bit AFI prepended.  Encoding of the
>        prefix, its AFI and the instance ID (IID) are specified by
>        [I-D.ietf-lisp-lcaf].  An XEID-prefix is used as a key index into
>        the database.
>
> These can be simplified by moving the details of the XEID format and
> the values of the fields into separate paragraphs (as discussed
> above).
>
>     DDT node:  a network infrastructure component responsible for
>        specific XEID-prefix and for delegation of more-specific sub-
>        prefixes to other DDT nodes.
>
> A DDT node can be authoritative for more than one prefix (see section
> 4.2 and section 10, paragraph 2), so "specific XEID-prefix" should be
> "specific XEID-prefix(es)".
>
>     DDT Map Resolver:  a network infrastructure element that accepts a
>        Map-Request, adds the XEID to its pending request list, then
>        queries one or more DDT nodes for the requested EID, following
>        returned referrals until it receives one with action code MS-ACK
>        (or an error indication).  MS-ACK indicates that the Map-Request
>        has been sent to a Map Server that will forward it to an ETR that,
>        in turn, will provide a Map-Reply to the original sender.  A DDT
>        Map Resolver maintains both a cache of Map-Referral message
>        results containing RLOCs for DDT nodes responsible for XEID-
>        prefixes of interest (termed the "referral cache") and a pending
>        request list of XEIDs that are being resolved through iterative
>        querying of DDT nodes.
>
> This isn't really a definition of what how Map Resolver fits into the
> overall scheme, but an outline of Map Resolver processing.  The
> description of processing should be moved somewhere else.  Also, any
> DDT client that is not a Map Resolver must do the same processing, so
> "DDT client" and "DDT Map Resolver" should be merged.
>
>     DDT Map-Request:  an Encapsulated Map-Request sent by a DDT client to
>        a DDT node.  The "DDT-originated" flag is set in the encapsulation
>        header ...
>
> Given the importance of Map-Request messages, it might be worth
> mentioning that they are defined in RFC 6830.
>
> What is the need for the DDT-originated flag?  It seems from the
> definition "Encapsulated Map-Request" that EMRs from ITRs to Map
> Resolvers never have the flag set, EMRs from Map Resolvers to DDT
> nodes (including Map Servers) always have the flag set, and EMRs from
> Map Servers to ETRs never have the flag set.  But if that is so, no
> type of device can receive EMRs that both have the flag set and not.
>
> Hmmm, the exception is if an ITR acts as a DDT client sends a
> Map-Request directly to DDT nodes.  But in that case, the DDT nodes
> would process the Map-Request in exactly the same way as a Map
> Resolver, so there is no need for a "D" flag.
>
> Also, the definition of the flag in section 5 is awkward:
>
>     D: The "DDT-originated" flag.  It is set by a DDT client to indicate
>        that the receiver SHOULD return Map-Referral messages as
>        appropriate.  Use of the flag is further described in
>        Section 7.3.1.  This bit is allocated from LISP message header
>        bits marked as Reserved in [RFC6830].
>
> If the flag *means* "DDT-originated", then the message must have come
> from a DDT client, and the receiver MUST return Map-Referral messages
> -- that's what this draft is specifying!
>
> I get the feeling that the D flat is (or was) intended to work like
> the DNS "recursion" flag, it tells whether the client is willing to
> accept and follow Map-Referral messages, or whether the client wants
> to put that work of following referrals on the server.  But as the
> lexicon makes clear, *any* DDT client must be willing to follow
> Map-Referral messages, and DDT nodes are *never* required to follow
> referrals on behalf of the DDT client.
>
>     Map-Referral:  a LISP message sent by a DDT node in response to a DDT
>        Map-Request for an XEID that matches a configured XEID-prefix
>        delegation.  A non-negative Map-Referral includes a "referral", a
>        set of RLOCs for DDT nodes that have more information about the
>        sub-prefix;
>
> The phrase "more information" is used in various places, but it is not
> really informative.  As far as I can tell, all uses of "DDT nodes that
> have more information" mean "DDT nodes to which that XEID has been
> delegated".  Unless perhaps hints are also considered to point to "DDT
> nodes that have more information", in which case the term "more
> information" needs to be defined specifically, as it doesn't always
> mean a delegation relationship.
>
>     Negative Map-Referral:  a Map-Referral sent in response to a DDT Map-
>        Request that matches an authoritative XEID-prefix but for which
>        there is no delegation configured (or no ETR registration if sent
>        by a DDT Map-Server).
>
> I'd describe a negative Map-Referral as an answer from an
> authoritative DDT node that there is no mapping for the requested
> XEID.  That happens because the request is sent to an authoritative
> DDT node "but for which there is no delegation configured (or no ETR
> registration if sent by a DDT Map-Server)", but the core semantics is
> an authoritative denial of a mapping.
>
>     Pending Request List:  the set of outstanding requests for which a
>        DDT Map Resolver has received encapsulated Map-Requests from a DDT
>        client for an XEID.
>
> Is it correct that a DDT Map Resolver can receive Map-Requests from
> DDT clients?  I thought a Map Resolver could only receive them from
> ITRs, and a DDT client could only send them to DDT nodes.  If a Map
> Resolver can receive requests from other Map Resolvers, there are
> complexities of behavior that don't seem to be described in this
> draft.
>
> In any case, does this need an entry in the lexicon?  It seems that a
> pending request list is an implementation detail and should be
> described in the algorithm description sections.
>
>     It is important to note that LISP-DDT does not store actual EID-to-
>     RLOC mappings; it is, rather, a distributed index that can be used to
>     find the devices (Map Servers and their registered EIDs) that can be
>     queried with LISP to obtain those mappings.
>
> This text defines that Map Servers are not part of DDT, but the
> lexicon refers to DDT Map Servers.  And actually, its the ETRs that
> store the EID-to-RLOC mappings, not the Map Servers (except when the
> Map Server is proxying for the ETR).
>
> 6.1.  Action codes
>
>     MS-ACK (2):  indicates that a replying DDT Map Server received a DDT
>
> s/a replying/the replying/
>
>     NOT-AUTHORITATIVE (5):  indicates that the replying DDT node received
>        a Map-Request for an XEID-request for which it is not
>        authoritative.  This can occur if a cached referral has become
>        invalid due to a change in the database hierarchy.
>
> There's a treacherous case of how hints are returned by a DDT node.
> Reading the above definition, it's clear that a hint should be
> returned with a NON-AUTHORITATIVE action code, because the node isn't
> authoritative for the XEID.  Then again, section 6.1 suggests that
> hints are returned as NODE-REFERRAL or MS-REFERRAL.  If so, things get
> messy -- How is the DDT client to know that the referral set is a hint
> rather than an authoritative delegation?  And that distinction is
> necessary because the client can't fully trust hints.
>
> 6.3.  Incomplete flag
>
>     o  If it is setting action code MS-ACK or MS-NOT-REGISTERED but does
>        not have configuration for other "peer" DDT nodes that are also
>        authoritative for the matched XEID-prefix.
>
> Is this situation equivalent to the referral set being a hint rather
> than a delegation?  Or rather, a hint which the DDT node doesn't
> believe is the complete peer set for the prefix?  (Is there any way
> for a DDT node to know that it has the complete peer set?)  In any
> case, it seems to me that this might be usefully changed to "hint
> flag".
>
> 6.4.  Map-Referral Message Format
>
> Is it intended that the "record" and "ref" sections can be repeated?
> That is a different usage of bracketing than in the figure in section
> 5, and if so, should be described in the text.
>
> I note that this section lists all the action codes, as does section
> 6.1.  It seems like these should be consolidated into section 6.1.
>
> The handling of the "Incomplete" column of the table cannot be
> correct.  There is no way for a node to send hints and mark them
> Incomplete, and the description at the top of page 12 is incompatible
> with the contents of the table.
>
>     Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be included in
>     the record.  If this is a LCAF AFI, the contents of the LCAF depend
>     on the Type field of the LCAF.  Security material are stored in LCAF
>     Type 11.  DDT nodes and Map Servers can use this LCAF Type to include
>     public keys associated with their Child DDT nodes for a XEID-prefix
>     referral record.  LCAF types and formats are defined in
>     [I-D.ietf-lisp-lcaf].
>
> This paragraph doesn't make sense in this context.  The terms "Loc",
> "keys", "LCAF", "Security material" are all undefined in this context.
>
>     Note, though,
>     that the set of RLOCs correspond to the DDT node to be queried as a
>     result of the referral not the RLOCs for an actual EID-to-RLOC
>     mapping.
>
> I take it that the "Ref" sections is counted by the "Referral Count"
> field, and that the "Loc/LCAF-AFI" and "Locator" fields contain the
> RLOCs of the set of DDT nodes that are the referral set.  It might
> help the reader to rephrase this sentence in those terms.
>
> 6.4.1.  SIG section
>
>     Sig Length: The length of the Signature field.
>
> Is this measured in bytes?
>
>     Signature: Contains the cryptographic signature that covers the
>     entire record.  The Record TTL and the sig fields are set to zero for
>     the purpose of computing the Signature.
>
> It's not clear to me why the Record TTL should be set to zero for
> computing the signature, given that you'd want to protect the TTL from
> modification.  Also, what is the relationship between Record TTL and
> Original Record TTL?  As far as I can tell, no DDT element can receive
> a Map-Referral Record from another element and pass it on to a third
> element, so there need never be TTL skew between when a record was
> signed and when it was sent.
>
> It seems awkward to compute the signature by first laying out the Sig
> section and filling it with zeros when the same benefit could be
> obtained by omitting the Sig section from the part of the record whose
> signature is calculated.
>
> Is it a problem that Original Record TTL, Signature Expiration, and
> Signature Inception aren't protected by the signature?
>
> 7.1.1.  Match of a delegated prefix (or sub-prefix)
>
>     If the delegation is known to be a DDT Map Server,
>
> This seems to assume that either all delegatees are Map Servers or
> none are.  All of the processing algorithms seem to presuppose that a
> set of peers either are all Map Servers or all are not, but there
> doesn't seem to be an explicit requirement of that.
>
> 7.1.2.  Missing delegation from an authoritative prefix
>
>     If the requested XEID did not match a configured delegation but does
>     match an authoritative XEID-prefix, then the DDT node MUST return a
>     negative Map-Referral that uses the least-specific XEID-prefix that
>     does not match any XEID-prefix delegated by the DDT node.
>
> It would be a bit clearer if "the least-specific XEID-prefix" was
> changed to "the least-specific prefix of the XEID".
>
>     If the requested XEID did not match either a configured delegation or
>     an authoritative XEID-prefix, then negative Map-Referral with action
>     code NOT-AUTHORITATIVE MUST be returned.
>
> I understand what you mean, but this isn't phrased quite right in
> regard to hints, because the DDT node may have a hint for an
> XEID-prefix that is neither a configured delegation nor within one of
> its authoritative XEID-prefixes, but hints are returned with
> NODE-REFERRAL.
>
> 7.3.  DDT Map Resolver
> 7.3.1.  Queuing and sending DDT Map-Requests
>
> I think there is an issue around the cache.  Usually (IMHO) when
> discussing "resolvers", the "cache" is entirely transient information
> that the resolver has acquired from other devices, it doesn't contain
> configured information.  But in some places, the draft reads as if the
> configured information is permanently present in the cache.  If that
> is so, it would help the reader (i.e., this reader!) if when the cache
> is introduced that it was stated that the configured delegations (and
> hints) are permanently resident in the cache.
>
> That is, this should be promoted from section 7.3.1 to 7.3 where the
> structure (rather than the detailed behavior) of a Map Resolver is
> discussed:
>
>     The referral cache is initially populated with one or more
>     statically-configured entries;
>
> Similarly this is a structural statement about the cache:
>
>     A DDT Map Resolver is not absolutely required to cache referrals,
>     but it doing so decreases latency and reduces lookup delays.
>
> --
>
>     Note that in normal use on the public Internet, the statically-
>     configured initial referral cache for a DDT Map Resolver should
>     include a "default" entry with RLOCs for one or more DDT nodes that
>     can reach the DDT root node.
>
> This suggests that it will be common that a Map Resolver won't be
> configured with the RLOCs of the root nodes (which is different from
> the common DNS usage), but rather configured with the RLOCs of nodes
> that contain a hint for the null prefix and the root nodes.  (Also,
> "can reach" should be changed to "containing hints for".)  If this is
> so, then the operation of hints is a central part of the DDT protocol
> and (IMO) it would greatly help if the role and processing of hints
> was outlined in some location.  In particular, it suggests that all
> nodes that are expected to be the initial node for an extensible
> population of Map Resolvers SHOULD be configured with a hint for the
> root nodes.
>
> There is also a possible conflict with section 10 -- the Map Resolver
> isn't expected to be configured with the RLOCs of the root servers,
> but it is expected to be configured with the public keys of the root
> servers.  Indeed, given the language in section 10, the keys can
> differ between the various root DDT nodes, which means that in order
> to configure the Map Resolver with the public keys of the root
> servers, it must be configured with their RLOCs.
>
> 7.3.2.  Receiving and following referrals
>
>     If the maximum number of retransmissions has occurred and all RLOCs
>     have been tried, then the pending request list entry is dequeued.
>
> This isn't phrased quite right, because it requires a further
> retransmission if "the maximum number of retransmissions has occurred"
> but not "all RLOCs have been tried" -- and that would mean sending
> more retransmissions than the "maximum number".
>
> I believe that the intention is that the Map Resolver must attempt to
> contact all relevant RLOCs, but that it must also send at least
> "number of retransmissions", meaning that if there are fewer RLOCs
> than that number, some RLOCs will be attempted more than once.  If
> that is so, then "maximum number" should be "minimum number".
>
> OTOH, if "maximum number" is intended, then the text should be "If the
> maximum number of retransmissions has occurred or all RLOCs have been
> tried".
>
> Also, this paragraph should specify what response the Map Resolver
> should send if processing is terminated due to response time-out.  As
> written, the text doesn't require the Map Resolver to send *any*
> response, which seems like a bad design.
>
>     MS-REFERRAL:  The DDT Map Resolver follows an MS-REFERRAL in the same
>        manner
>
> It might be better to say "processes" than "follows".
>
>     MS-ACK:  This is returned by a DDT Map Server to indicate that it has
>        one or more registered ETRs that can answer a Map-Request for the
>        XEID and the request has been forwarded to one of them
>
> It's not clear to me how the Map Server or ETR knows the address of
> the DDT client to which to send the Map-Reply.  It seems that the
> address must be in the Map-Request message, but reading that section
> of RFC 6830 doesn't make it clear to me how that is done.
>
> The processing regarding MS-ACK is not clear to me.  It would help if
> there was an overview discussion of the four-way dance between the DDT
> client, the Map Resolver, the Map Server, and the ETR.  (Some times
> the Map Server also does the ETR's job.)  Since one step of it is for
> the ETR to send Map-Replay to the DDT client, this processing doesn't
> break down into separate client/Map Resolver, Map Resolver/Map Server,
> and Map Server/ETR components, there's a specific overall structure.
>
> In particular, what happens when a Map Resolver sends a Map-Request to
> a Map Server without LISP-SEC information?  It appears that processing
> goes through two cycles, with a second cycle when the Map Resolver
> re-sends the Map-Request to the Map Server with LISP-SEC information.
> The Map Server seems to return MS-ACK messages to the Map Resolver in
> both cycles, and there is no special marking in the first MS-ACK
> message to indicate that resending must be done (the Map Resolver can
> determine that itself).  But presumably, the Map Server forwards the
> Map-Request to the ETR in both cycles, and the ETR sends Map-Replys to
> the client in both cycles.  Presumably the first Map-Reply is useless
> to the client (otherwise there wouldn't need to be two cycles), but
> it's not clear how the client deals with two replies.
>
>     MS-NOT-REGISTERED:  ...
>        The DDT Map Resolver MUST return a negative
>        Map-Reply to the original Map-Request sender; this Map-Reply
>        contains the non-registered XEID-prefix whose TTL value SHOULD be
>        set to one minute.
>
> I think "non-registered XEID-prefix" is meant to mean "least-specific
> prefix of the XEID for which no registrations exist".
>
>     NOT-AUTHORITATIVE:  ...
>        The pending request is silently discarded, i.e. all state
>        for the request that caused this answer is removed and no answer
>        is returned to the original requester.
>
> It seems like a poor design to return no response.  Is there not some
> sort of "server failure" response that can be returned to the DDT
> client?
>
> 8.  Pseudo Code and Decision Tree diagrams
>
> Care needs to be taken here as to whether the pseudo-code and decision
> trees are normative or not.  Generally, algorithms enunciated in RFCs
> are marked as non-normative, as the implementation is usually allowed
> to deviate from the stated algorithm as long as it satisfies the
> constraints written in the text.
>
> 9.  Example topology and request/referral following
>
>     The same principle
>     of hierarchical delegation and pinpointing referrals is equally
>     applicable to any AF whose address hierarchy can be expressed as a
>     bitstring with associated length.
>
> This sentence seems to be redundant because we've been assuming all
> along that in any address family used by DDT the address hierarchy is
> expressed as bistrings with lengths.
>
> Are lines in the diagram intended to cross?  If so, they could be
> clarified as:
>
>        +---------------------+  +---------------------+
>        |  root1: 192.0.2.1   |  |  root2: 192.0.2.2   |
>        | authoritative: ::/0 |  | authoritative: ::/0 |
>        +---------------------+  +---------------------+
>                   |         \   /        |
>                   |          \ /         |
>                   |           X          |
>                   |          / \         |
>                   |         /   \        |
>                   |        |     |       |
>                   V        V     V       V
>    +-------------------------+  +--------------------------+
>    |  DDT node1: 192.0.2.11  |  |  DDT node2: 192.0.2.12   |
>    |     authoritative:      |  |      authoritative:      |
>    |      2001:db8::/32      |  |       2001:db8::/32      |
>    +-------------------------+  +--------------------------+
>                   |         \   /        |
>                   |          \ /         |
>                   |           X          |
>                   |          / \         |
>                   |         /   \        |
>                   |        |     |       |
>                   V        V     V       V
>   +--------------------------+  +---------------------------+
>   | Map-Server1: 192.0.2.101 |  |  DDT node3: 192.0.2.201   |
>   |      authoritative:      |  |      authoritative:       |
>   |    2001:db8:0100::/40    |  |    2001:db8:0500::/40     |
>   | site1: 2001:db8:0103::/48|  +---------------------------+
>   | site2: 2001:db8:0104::/48|     |                    |
>   +--------------------------+     |                    |
>                                    |                    |
>                                    |                    |
>                                    V                    V
>             +---------------------------+   +---------------------------+
>             | Map-Server2: 192.0.2.211  |   | Map-Server3: 192.0.2.221  |
>             |      authoritative:       |   |      authoritative:       |
>             |    2001:db8:0500::/48     |   |    2001:db8:0501::/48     |
>             |site3: 2001:db8:0500:1::/64|   |site5: 2001:db8:0501:8::/64|
>             |site4: 2001:db8:0500:2::/64|   |site6: 2001:db8:0501:9::/64|
>             +---------------------------+   +---------------------------+
>
>
> 10.  Securing the database and message exchanges
>
>     Each DDT node is configured with one or more public/private key
>     pair(s) that are used to digitally sign referral records for XEID-
>     prefix(es) that the DDT node is authoritative for.  In other words,
>     each public/private key pair is associated with the combination of a
>     DDT node and the XEID-prefix that it is authoritative for.
>
> s/the XEID-prefix/an XEID-prefix/
>
> But the first sentence doesn't say the same thing as the second
> sentence.  Better would be
>
>     Each DDT node is configured with one or more public/private key
>     pairs for each XEID-prefix that it is authoritative for, and those
>     keys are used to sign referral records for XEID-prefixes within the
>     authoritative XEID-prefix.
>
> Also, there should be some text as to whether a node is required to
> sign a referral record with *all* of its keys.  And in general, there
> should be some discussion of the significance and use of multiple keys
> for a single DDT node/authoritative prefix.
>
>     Every DDT
>     node is also configured with the public keys of its children DDT
>     nodes.  By including public keys of target child DDT nodes in the
>     Map-Referral records, and signing each record with the DDT node's
>     private key, a DDT node can securely delegate sub-prefixes of its
>     authoritative XEID-prefixes to its children DDT nodes.
>
> Does a DDT node have the public keys of the DDT nodes that its hints
> point to?  If not, hints can't be trusted and followed in the same way as
> "downward" Map-Referrals, which breaks the trust sequence if the DDT
> client is not configured with the keys of the RLOCs in the hint.
>
> Also, how does the DDT node return public keys to the Map Resolver?  I
> don't see any field for it in the Map-Referral message.
>
> 11.  Open Issues and Considerations
>
>     o  Management of the DDT Map Resolver referral cache, in particular,
>        detecting and removing outdated entries.
>
> I assume that this means "the definition and use of TTL values",
> because the use of TTL values does not seem to be completely described
> in this document.  Perhaps this item could be rephrased to mention TTL
> explicitly.
>
> 13.  Security Considerations
>
>     For this reason, when
>     LISP-SEC is deployed in conjunction with a LISP-DDT mapping database
>     and the path between Map-Resolver and Map-Server needs to be
>     protected, DDT security should be enabled as well.
>
> This sentence is obscure, because "DDT security" is not defined
> anywhere, and there seems to be no optional security mechanism
> described in the draft.
>
> 14.2.  Informative References
>
>     [I-D.ietf-lisp-lcaf]
>                Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
>                Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work in
>                progress), May 2016.
>
> The reference to ietf-lisp-lcaf in the definition "XEID-prefix" in
> section 3 seems to be normative (unless the text in this draft is
> adjusted to consider XEIDs as undifferentiated bit strings).
>
>     [LISP-TREE]
>                Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
>                and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support
>                the lisp mapping system", Selected Areas in
>                Communications, IEEE Journal , 2010,
>                <http://ieeexplore.ieee.org/xpls/
>                abs_all.jsp?arnumber=5586446>.
>
> This reference is not referenced.
>
>     [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
>                Standards (PKCS) #1: RSA Cryptography Specifications
>                Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
>                2003, <http://www.rfc-editor.org/info/rfc3447>.
>
> The reference to RFC 3447 in section 6.4.1 seems to be normative, as
> the specifics of RSA-SHA1 signatures come from this RFC.
>
> Dale