Hi Albert, On Wed, Sep 30, 2020 at 01:31:42AM +0200, Albert Cabellos wrote: > Hi > > I´ve posted -29 following your comments, please find inline specific > responses:
Thanks. I'll respond to a few things inline, and will then go update my ballot position. (To No Objection, hooray!) > On Thu, Jul 9, 2020 at 6:26 AM Benjamin Kaduk via Datatracker > <[email protected]> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lisp-rfc6833bis-27: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > (1) The -27 brought back the "MUST" for HMAC-SHA256-128 in Section 5.6 per > > my ballot on the -26, but left unchanged section 9, so we still have a > > SHOULD vs. MUST inconsistency w.r.t. implementing > > HMAC-SHA256-128+HKDF-SHA256. (I would of course prefer the same > > resolution of the inconsistency that Roman does, but have forgotten to > > what extent we have to defer to the deployed reality.) > > > > From a deployment reality perspective, I think that this makes sense: > > Implementations of this specification MUST implement > HMAC-SHA-256-128 and SHOULD implement HMAC-SHA256-128+HKDF-SHA256 > > Now it is consistent across the document. Please let me know your view on > this. I think I am resigned to this, since we only added the HKDF stuff at IESG Evaluation stage. (I suppose Roman or someone else could feel otherwise, though.) > > > > (2) It looks like the update in Section 5.7 is attempting to address my > > point about only terminating Map-Notify retransmission when the > > authentication data of the Map-Notify-Ack validates, but the added text > > is either misplaced or malformed. Perhaps > > > > CURRENT: > > The Map-Notify-Ack message has the same contents as a Map-Notify > > message. It is used to acknowledge the receipt of a Map-Notify and > > for the sender to stop retransmitting a Map-Notify with the same > > nonce and the authentication data validates. [...] > > > > NEW: > > The Map-Notify-Ack message has the same contents as a Map-Notify > > message. It is used to acknowledge the receipt of a Map-Notify and, > > once the the authentication data is validated, allows for the > > Map-Notify sender to stop retransmitting a Map-Notify with the same > > nonce. [...] > > > > Changed, thanks. > > > (3) I think that Eric Rescorla's concern about a misbehaving ETR being > > able to prevent an ITR from learning that the ETR is no longer the > > appropriate ETR for a given prefix remains unaddressed. I wrote up a > > longer description at > > https://mailarchive.ietf.org/arch/msg/lisp/O2ycn4CkWsPhFyqrZuB4ZJBNnl0/ > > but in short, we only require the ITR to send its Map-Request through > > the mapping system (vs. directly to the ETR) when SMR is sent from an > > address not in the current mapping data for that prefix -- if the SMR is > > sent from an address in the current mapping data, we allow sending > > Map-Request directly to the ETR, outside the mapping system. I don't > > see a mechanism that guarantees that such a "revocation" event is > > noticed by the ITR. > > > > Updated the section, now all SMR-invoked Map-Requests MUST be sent > through the Mapping System (This is what deployments are doing): > > An SMR message is simply a bit set in a Map-Request message. > An ITR or PITR will send a Map-Request (SMR-invoked > Map-Request) when they receive an SMR > message. While the SMR message is sent through the > data-plane, the SMR-invoked Map-Request > MUST be sent through the Mapping System (not directly). Thanks, that does make me feel better about how things work. > > > (4) The specification of the MAC+KDF algorithms doesn't seem detailed > > enough to be implementable. RFC 4868 is attempted to be used as a > > reference for both HMAC-SHA256-128 (er, and the one-character-off > > HMAC-SHA-256-128) and HKDF-SHA2562 (note spurious final '2'), but I > > think it can only work as a reference for the MAC algorithm. Presumably > > we need RFC 5869 or such for the KDF part > > > > Fixed, thanks. > > > > (5) This is probably my fault, but we're missing a step with how we > > describe the Map-Notify/Map-Notify-Ack per-message authentication. > > Specifically, while we do say that the authentication data needs to be > > recomputed each time, we don't clearly state that this is because the > > correct per-message key is different, because we are using a different > > 's' input to the KDF function for the different messages. In line with > > the "Map-Register Authentication" used for Map-Register, this would > > presumably be "Map-Notify Authentication" and "Map-Notify-Ack > > Authentication", but neither of those strings appear in this document. > > We might be able to localize the change to Section 5.6, akin to > > > > OLD: > > 4: The derived per-message key is computed as: per-msg- > > key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in > > the Nonce field of the Map-Register and 's' is a string equal > > to "Map-Register Authentication". [...] > > > > NEW: > > 4: The derived per-message key is computed as: per-msg- > > key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in > > the Nonce field of the Map-Register and 's' is a string that > > corresponds to the message type being authenticated. For > > Map-Register messages, it is equal to "Map-Register > > Authentication". Similarly, for Map-Notify and Map-Notify-Ack > > messages, it is "Map-Notify Authentication" and > > "Map-Notify-Ack Authentication", respectively. > > > > Fixed. > > > However, I think the rhetoric would be more robust if we also modified > > Section 5.7 to mention the existence of the different 's' values (or, > > rather, the different per-message key) when we say that the > > authentication data is recomputed. Perhaps, s/is recomputed/is > > recomputed using the corresponding per-message key/ (twice). > > > > > > Fixed, thanks. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Abstract > > > > database designs. Since these devices implement the "edge" of the > > LISP Control-Plane infrastructure, connecting EID addressable nodes > > of a LISP site, their implementation and operational complexity > > reduces the overall cost and effort of deploying LISP. > > > > I think there might be a "simplifying" or "reducing" missing here > > (w.r.t. "their implementation and operational complexity"). > > > > Fixed. > > > Section 1 > > > > Conceptually, LISP Map-Servers share some of the same basic > > configuration and maintenance properties as Domain Name System (DNS) > > [RFC1035] servers; likewise, Map-Resolvers are conceptually similar > > > > I suggest adding "authoritative" to the DNS servers of the analogy. > > > > Fixed. > > > Section 3 > > > > Map-Resolver: A network infrastructure component that accepts LISP > > Encapsulated (ECM) Map-Requests, typically from an ITR, and > > determines whether or not the destination IP address is part of > > the EID namespace; if it is not, a Negative Map-Reply is returned. > > Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC > > mapping by consulting a mapping database system. > > > > This could perhaps be misread as implying that the Map-Resolver returns > > the appropriate EID-to-RLOC mapping to the requestor directly, whereas > > IIRC the reply is sent directly from the ETR/Map-Server. > > > > Fixed. > > > Section 4 > > > > A Map-Server is a device that publishes EID-Prefixes in a LISP > > mapping database on behalf of a set of ETRs. When it receives a Map > > Request (typically from an ITR), it consults the mapping database to > > > > I feel like I said this already but forgot the answer; sorry for the > > duplication: the Map-Server is not getting the request directly from the > > ITR, but rather from the mapping system or a Map-Resolver. Do we want > > to say something like "originating from an ITR" to clarify? > > > > Fixed. > > > > Section 5.2 > > > > A: This is an authoritative bit, which is set to 0 for UDP-based Map- > > Requests sent by an ITR. It is set to 1 when an ITR wants the > > destination site to return the Map-Reply rather than the mapping > > database system returning a Map-Reply. > > > > I'm not sure this paints a clear picture of when the bit is/isn't set. > > Are Map-Requests sent by an ITR that want the destination site to reply > > (rather than the mapping database) sent over some non-UDP-based scheme? > > Do ECM messages count as UDP-based? > > (I would make this a Discuss for lack of clarity but that would be > > double-jeopardy.) > > > > Reworded to: > > <t hangText="A:"> This is an authoritative bit, it is set to 1 > when an ITR wants the destination site to return the Map-Reply > rather than the mapping database system returning a Map-Reply, and > set to 0 otherwise. > > for clarification. Sounds good. (The first comma is a comma splice, but I'm sure the RFC Editor will pick up on it if we don't fix it before then.) > > p: This is the PITR bit. This bit is set to 1 when a PITR sends a > > Map-Request. > > > > It might be worth saying something about what the recipient would do > > with the knowledge that the Map-Request was PITR-generated (rather than > > ITR-generated?). > > > > Added “the use of this bit is deployment-specific”. Ah, fair enough. > > > L: This is the local-xtr bit. It is used by an xTR in a LISP site to > > tell other xTRs in the same site that it is part of the RLOC-set > > for the LISP site. The L-bit is set to 1 when the RLOC is the > > sender's IP address. > > > > I'm not sure which RLOC is "the" RLOC -- the message format seems to > > allow multiple ITR-RLOC entries. > > > > This is used when multiple XTR serve the same EID on the same LISP-site. > > > > D: This is the dont-map-reply bit. It is used in the SMR procedure > > described in Section 6.1. When an xTR sends an SMR Map-Request > > message, it doesn't need a Map-Reply returned. When this bit is > > > > Should this get s/SMR Map-Request message/SMR message/ as was done > > elsewhere in response to my comments on a previous version? > > > > Agreed, changed > > > > EID-Prefix: This prefix address length is 4 octets for an IPv4 > > address family and 16 octets for an IPv6 address family when the > > EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the > > address length varies and for the LCAF AFI the format is defined > > in [RFC8060]. [...] > > > > Just to check: if I get a Map-Request that uses an AFI I don't > > recognize, I have to abort parsing the packet since I don't know how > > many bytes to skip? It seems like this might negatively affect the > > ability to introduce new AFIs. > > > > Good catch, added this sentence: > > LISP control-plane messages that include an unrecognized AFI MUST be > dropped and the event MUST be logged. Thanks. > > > Map-Reply Record: When the M-bit is set, this field is the size of a > > single "Record" in the Map-Reply format. This Map-Reply record > > contains the EID-to-RLOC mapping entry associated with the Source > > EID. This allows the ETR that will receive this Map-Request to > > cache the data if it chooses to do so. > > > > We could perhaps mention something about whether the ETR believes the > > message is trustworthy, too, since it does not have the benefit of > > having gone through mapping system validation. > > > > Added “It is important to note that this mapping has not been > validated by the Mapping System.” > > > > Section 5.3 > > > > Map-Requests MUST be rate-limited to 1 per second per EID-prefix. > > After 10 retransmits without receiving the corresponding Map-Reply > > must wait 30 seconds. > > > > nit: incomplete sentence. > > > > Added “… the sender...” > > > > a Map-Cache entry. If the ETR (when it is an xTR co-located as an > > ITR) has a Map-Cache entry that matches the "piggybacked" EID and the > > RLOC is in the Locator-Set for the cached entry, then it MAY send the > > "verifying Map-Request" directly to the originating Map-Request > > source. If the RLOC is not in the Locator-Set, then the ETR MUST > > send the "verifying Map-Request" to the "piggybacked" EID. Doing > > this forces the "verifying Map-Request" to go through the mapping > > database system to reach the authoritative source of information > > about that EID, guarding against RLOC-spoofing in the "piggybacked" > > mapping data. > > > > side note: Does it make much practical difference to send the > > Map-Request to the EID as the destination address vs. just consulting > > the mapping system to look up that EID? It seems like the former is > > strictly more work, and I'm not sure what additional benefit is gained > > from that additional work. I guess, reachability information for the > > EID in question. > > > > Updated to: > > An ITR that is configured with mapping database information > (i.e., it is also an ETR) MAY optionally include those mappings > in a Map-Request. When an ETR configured to accept and verify > such "piggybacked" mapping data receives such a Map-Request and > it does not have this mapping in the Map-Cache, it MUST originate > a "verifying Map-Request" through the mapping database to validate > the "piggybacked" mapping data. > > > > > Section 5.4 > > > > P: This is the probe-bit, which indicates that the Map-Reply is in > > response to a Locator reachability probe Map-Request. The 'Nonce' > > field MUST contain a copy of the nonce value from the original > > Map-Request. [...] > > > > The description of the nonce field says that it's always copied from the > > Map-Request; is this MUST adding any additional requirements? > > > > Updated to “must” > > > > Record Count: This is the number of records in this reply message. > > A record is comprised of that portion of the packet labeled > > 'Record' above and occurs the number of times equal to Record > > Count. > > > > We say earlier that the record count in a Map-Request is (artificially) > > limited to 1 for this document; we might note here that the reply count > > can be larger than the request count, e.g., when there's a need to > > return more-specifics that are carved out from the best match to the > > requested EID. > > > > Changed. > > > > Locator Count: This is the number of Locator entries in the given > > Record. A Locator entry comprises what is labeled above as 'Loc'. > > The Locator count can be 0, indicating that there are no Locators > > for the EID-Prefix. > > > > Do we want to say "also known as a negative Map-Reply"? > > > > There are other reasons for a 0 locator count. My mistake; sorry. > > > (0) No-Action: The Map-Cache is kept alive, and no packet > > encapsulation occurs. > > > > (1) Natively-Forward: The packet is not encapsulated or dropped > > but natively forwarded. > > > > It might be worth a few words about how these two differ, as the "no > > encapsulation" part is superficially similar. > > > > A: The Authoritative bit MAY only be set to 1 by an ETR. A Map- > > Server generating Map-Reply messages as a proxy MUST NOT set the > > A-bit to 1 by an ETR, and not a Map-Server generating Map-Reply > > messages as a proxy. This bit indicates to requesting ITRs that > > > > nit: looks like a botched edit, with the "and not a Map-Server > > generating Map-Reply messages as a proxy" sticking around when it should > > have been removed. > > > > Fixed, thanks. > > > > the Map-Reply was not originated by a LISP node managed at the > > site that owns the EID-Prefix. > > > > Please confirm that the "not" is correct, here. > > > > Typo, thanks. Changed to: > > This bit indicates to the requesting ITRs if the Map-Reply was > originated by a LISP node managed at the site that owns the > EID-Prefix. > > > 12.5% of the traffic. If all Weights for a Locator-Set are equal, > > the receiver of the Map-Reply will decide how to load-split the > > traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a > > > > "equal" or "equal to zero"? Just "equal" seems like it needlessly > > overloads the semantics for uniform balancing. (Similarly for the > > multicast weight.) > > > > “equal” seems correct to me. > > > > R: This is set when the sender of a Map-Reply has a route to the > > Locator in the Locator data record. This receiver may find this > > useful to know if the Locator is up but not necessarily reachable > > from the receiver's point of view. See also EID-Reachability > > Section 7.1 for another way the R-bit may be used. > > > > I'm not finding mention of the R-bit in Section 7.1; am I missing > > something? > > > > correct, removed reference to section 7.1 This was a leftover from > previous edits. > > > > The Record format, as defined here, is used both in the Map-Reply and > > Map-Register messages, this includes all the field definitions. > > > > (We also mentioend in the previous section that a single record in this > > format can be present in the Map-Request.) > > > > Section 5.5 > > > > either from the destination field of an IP header of a Data-Probe or > > the EID record of a Map-Request. The RLOCs in the Map-Reply are > > > > nit(?): "EID of a record of a Map-Request"? > > > > You are right, updated. > > > > invoking the reply. The source address of the Map-Reply is one of > > the local IP addresses chosen, to allow Unicast Reverse Path > > > > Something seems amiss here. It might just be that the comma is > > misplaced (after chosen vs. before it), but that hinges on the nature of > > the choice in question. > > > > Section 5.6 > > > > E: This is the Map-Register EID-notify bit. This is used by a First- > > Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify > > based Map-Register is sent by the FHR to the same site xTR that > > propogates the Map-Register to the mapping system. The site xTR > > > > nit(???): I think maybe s/the same site/a same-site/, though that > > > nominally changes the meaning. > > > > You are right, updated. > > > 4: The derived per-message key is computed as: per-msg- > > key=KDF(nonce+s+PSK[Key ID]). Where the nonce is the value in > > > > There's some notational quirks to handle here, since a KDF() function is > > typically represented as taking two inputs, an input key material and a > > salt, and depending on context an output length as well. (Though > > resolving this may depend on how discuss point (4) is resolved.) > > > > We should probably also say that '+' is used to represent concatenation. > > > > Updated to, please let me know if this is correct: > > The derived per-message key is computed as: > per-msg-key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in > the Nonce field of the Map-Register, '+' denotes concatenation and 's' > (the salt) is a string that corresponds to the message type being > authenticated. For Map-Register messages, it is equal to > "Map-Register Authentication". Similarly, for Map-Notify and > Map-Notify-Ack messages, it is "Map-Notify Authentication" and > "Map-Notify-Ack Authentication", respectively. For those Algorithm IDs > defined in <xref target="KEYS"/> that specify a 'none' KDF, the > per-message key is computed as: per-msg-key = PSK[Key ID]. This means > that the same key is used across multiple protocol messages. That should work; thanks. > > Section 5.7 > > > > procedure defined in the previous section. For an unsolicited Map- > > Notify, the fields of a Map-Notify used for publish/subscribe are > > specified in [I-D.ietf-lisp-pubsub]. > > > > We probably want to tweak how we make this reference to avoid a > > perceived need to make pubsub a normative reference. Perhaps something > > like "the Map-Notify message can also used, outside the scope of this > > specification, in an unsolicited manner, such as is specified in > > [pubsub]". Also, there are other ways to get an unsolicited Map-Notify, > > right? This text doesn't really make that clear. > > > > Right, updated. > > > > A Map-Server sends an unsolicited Map-Notify message (one that is not > > used as an acknowledgment to a Map-Register message) in only > > > > nit: s/in only/only in/ (my fault, sorry) > > > > conformance the Congestion Control And Relability Guideline sections > > of [RFC8085]. A Map-Notify is retransmitted until a Map-Notify-Ack > > > > nit: s/conformance/conformance with/ > > > > Fixed both typos, thanks. > > > Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the > > receiver verifies the authentication data. > > > > I suggest adding "If the authentication data fails to validate, the > > message is dropped without further processing". > > > > Added > > > Section 5.8 > > > > LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", > > and what follows is either an IPv4 or IPv6 header as encoded by > > the first 4 bits after the 'Reserved' field. > > [...] > > S: This is the Security bit. When set to 1, the field following > > the 'Reserved' field will have the following Authentication > > Data format and follow the procedures from [I-D.ietf-lisp-sec]. > > > > So is it the IP version or the authentication data that follows the > > Reserved field? > > > > Correct, updated to: > > <t hangText="LISP:">Type 8 is defined to be a "LISP Encapsulated > Control Message", and what follows is either an IPv4 or IPv6 > header as encoded by the first 4 bits after the 'Reserved' > field, or the Authentication Data field <xref > target="I-D.ietf-lisp-sec"/> if the S-bit (see below) is set.</t> > > > Section 6.1 > > > > mapping data. Please note that this procedure does not result in > > cryptographic or strongly authenticated verification. > > > > "in the absence of [LISP-SEC]". > > > > > This text has already changed per another edit. > > > > When an ITR receives an SMR-based Map-Request for which it does not > > > > One more s/SMR-based Map-Request/SMR message/, I think (I missed it in > > my review of the -26). > > > > Updated in a previous edit. > > > Section 7 > > > > 4. An ITR may receive a Map-Reply from an ETR in response to a > > previously sent Map-Request. The RLOC source of the Map-Reply is > > likely up, since the ETR was able to send the Map-Reply to the > > ITR. > > > > I note that in the analogous text in 6830bis (Section 10), we have a > > furthe statement "Please note that in some scenarios the RLOC [from the > > outer header] can be an spoofable field." > > > > Added. > > > > When ITRs receive ICMP Network Unreachable or Host Unreachable > > messages as a method to determine unreachability, they will refrain > > from using Locators that are described in Locator lists of Map- > > Replies. However, using this approach is unreliable because many > > network operators turn off generation of ICMP Destination Unreachable > > messages. > > > > I think there is also some level of unreliability in the other direction > > -- even when following draft-ietf-opsec-icmp-filtering and validating > > the echoed contents, the contents could in some cases be sufficiently > > predictable that an attacker could spoof them. Having random > > nonces/ports be in use helps, of course, but the ICMP message could be > > generated in response to arbitrary traffic, not all of which will > > necessarily have all of those. > > > > The ITR can test the reachability of the unreachable Locator by > > sending periodic Requests. Both Requests and Replies MUST be rate- > > > > nit: I think we haven't been using the bare forms of "Requests" and > > "Replies" (in favor of the "Map-" prefixed forms). > > > > Agreed, updated. > > > > Section 8.1 > > > > > o A Negative Map-Reply, with action code of "Natively-Forward", from > > a Map-Server that is authoritative (within the LISP deployment > > Section 1.1) for an EID-Prefix that matches the requested EID but > > that does not have an actively registered, more-specific EID- > > prefix. In this case, the requested EID is said to match a "hole" > > > > Presumably the more-specific prefix still needs to match the requested > > EID? > > > > > It has a less-specific matching the EID, and a more-specific ‘hole’ > (not registered) matching the EID. > > > Section 9 > > > > 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network > > operartors should carefully weight how the LISP-SEC threat model > > > > nit: s/operartors/operators > > > > Fixed in a previous edit. > > > The Map-Request/Map-Reply message exchange to inject forged mappings > > directly in the ITR EID-to-RLOC map-cache. This can lead to traffic > > > > nit: the grammar's a bit off, maybe s/to inject/can inject/? > > > > Added “…can also be exploited…” That works too; thanks. Thanks as well for all the other updates that I didn't comment on specifically! -Ben > > attacks. In this case, attackers can claim to own an EID-prefix that > > is larger than the prefix owned by the ETR. Such attacks can be > > > > I'd consider adding ", since the Map-Reply is sent directly from ETR to > > ITR without a chance for validation by the mapping system". > > > > addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC > > protocol defines a mechanism for providing origin authentication, > > integrity, protection, and prevention of 'man-in-the-middle' and > > > > nit: s/integrity,/integrity/ (spurious comma) > > > > Removed comma. > > > replay attacks by a man-in-the-middle. However, a compromised ETR > > can overclaim the prefix it owns and successfully register it on its > > corresponding Map-Server. To mitigate this and as noted in > > > > The "can overclaim" is a little weird since we go on to describe the > > mandatory mitigation against this attack. Maybe something with "could" > > or a more drastic rewording to "there is a potential attack where a > > compromised ETR could"? > > > > Updated. > > > > Section 11 > > > > [I did not attempt to double-check that the listed changes match the > > actual differences between RFC 6833 and this document, but do note that > > it looks like the authors did so at some point since my initial review.] > > > > o This document is incorporating the codepoint for the Map-Referral > > message from the LISP-DDT specification [RFC8111] to indicate that > > a Map-Server must send the final Map-Referral message when it > > participates in the LISP-DDT mapping system procedures. > > > > It's pretty hard to claim that RFC 8111 is only an informative reference > > in light of statements like this that a Map-Server needs to do something > > from it when a flag bit defined by this document is set. > > > > Section 12.3 > > > > New ACT values can be allocated through IETF review or IESG approval. > > Four values have already been allocated by [RFC6830], IANA is > > requested to replace the [RFC6830] reference for this registry with > > the RFC number assigned to this document and the [RFC6830]. Action > > > > nit: comma splice. > > Updated. > > > > > values references with the RFC number assigned to this document. > > > > nit: incomplete sentence (lingering remnants of a previous edit that > > should just get removed?) > > > > Fixed. > > > Section 12.4 > > > > The IANA registry "LISP Canonical Address Format (LCAF) Types" is > > used for LCAF types. The registry for LCAF types use the > > Specification Required policy [RFC8126]. Initial values for the > > > > "Specification Required" includes review by designated experts. Do we > > want to give any guidance to the experts for reviewing new submissions? > > (Similarly for other registries; I note that the LISP Bit Flags section > > doesn't use the "Specification Required" keyword.) > > > > Section 13.1 > > > > We don't currently cite RFC 6347 in a way that requires a normative > > reference. Though I for one wouldn't mind if we made DTLS mandatory > > somewhere :) > > > > Section 13.2 > > > > We nominally have a "MUST" for behavior from RFC 1071, that would make > > it a normative reference, but this is pretty foundational so it seems a > > bit like overkill. > > > > > > > > _______________________________________________ > > lisp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
