From nobody Tue Nov 1 11:46:04 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C571129868 for ; Tue, 1 Nov 2016 11:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40NycnanRlju for ; Tue, 1 Nov 2016 11:45:58 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5009A12986D for ; Tue, 1 Nov 2016 11:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37586; q=dns/txt; s=iport; t=1478025957; x=1479235557; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dh7OCv9r1YfpRYMryEVTRBOfP1kdq6d2yo4Xh+DE328=; b=Gy99ZAbqMML6RzBy3Wqg0nSbcCxjNhP8a6Z510F6eKcPg25WVV2um3YS I3R3KdAcwBlPLOD5Aj5uucSLmksV8KpdR52x1bkwi1nFths9uYw/6kpZV rI3d/s1fFmb455fgw/dHPztHhz+U+pK6Bi+2SN1A8wmBS1tcmB6++P5ss E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAgAB4hhY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAXcDJ1KNNpcBjDOIEoIEAx0LhXoCglIUAQIBAQEBAQE?= =?us-ascii?q?BYiiEYgEBBAEBARcBHTYEFwsUBC4nMAYBDAYCAQEFiEsOuAwBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEchj2BfQiBS4EFhBkRAQaFdgWIRpFUhjGCRUSGe4FuToQggxc?= =?us-ascii?q?jhXCHIYFvhAOEBB42UgYIgyEDHIFUPTQBhSAFAggXghUBAQE?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="647796682" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 18:45:53 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA1IjqO7007625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2016 18:45:53 GMT To: "Dale R. Worley" , lisp@ietf.org References: <87bmym4cyp.fsf@hobgoblin.ariadne.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: <59a92e60-6434-44f5-26d9-adeedc4fb537@cisco.com> Date: Tue, 1 Nov 2016 19:45:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87bmym4cyp.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 18:46:01 -0000 Hello Dale, thanks for your very detailed and extensive comments. Dino has already provided inline answers for your comments and authors [mostly] agree with them. So we are planning to update the draft to address points raised in your review - either by taking in proposed changes or by clarifying the text to better express author's intentions. Given extent of your comments it will take us some time to edit the document. Next revision will hopefully reduce number of places which needs further discussion, so it will be easier to have email discussion of remaining issues. Anton On Saturday 15 October 2016 03:29, 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 > . > > 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, > 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, . > > 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 > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Nov 1 11:47:24 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5931D129868 for ; Tue, 1 Nov 2016 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6nZjVUAH2u6 for ; Tue, 1 Nov 2016 11:47:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF6112985F for ; Tue, 1 Nov 2016 11:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44875; q=dns/txt; s=iport; t=1478026039; x=1479235639; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GJ4XdrSN+Z1/1rb2hwU1AQxeENkFBLMM4ZpF4VxGgqQ=; b=m40Zf/dHRBRq6/83oRIEc5p7FExGO0U/Ho2xMKI6qsVXYEP4q8SyuVJK S5YNPG7LovBiu2PaMObbzarZmJ9tx86yF0e6zsOjIYfAq0oNvxHgmfWbl bQE49R4B3Hb9eiSwlKxyGeseSB/gpGHUm+lbuaNr0AXasLcgI2gR36Pkm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRBAAB4hhY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAXcDJwNPgwGKNZcBjDOIEoIEAx0LhXoCglIUAQIBAQE?= =?us-ascii?q?BAQEBYiiEYQEBAQMBAQEBCQ4BCA8BBTYEBxAJAhICBAICJgICJyIOBgEMBgIBA?= =?us-ascii?q?QUQiDMIDo1UnTaNAgEBAQEBAQEBAQEBAQEBAQEBAQEBHYEHhTaBfYFTgQWEMYM?= =?us-ascii?q?aglwFiEaGCItMhjGCRUSGe4FuToQggxcjhXCJEIQDhAQeNlIGCIMhAgEcgVQ9N?= =?us-ascii?q?AGFIAUCgjQBAQE?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="647796703" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 18:47:14 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA1IlEMi000724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2016 18:47:14 GMT To: Dino Farinacci , "Dale R. Worley" References: <87bmym4cyp.fsf@hobgoblin.ariadne.com> <50795FAC-6560-4F02-937B-F6343F1E6CF7@gmail.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: Date: Tue, 1 Nov 2016 19:47:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <50795FAC-6560-4F02-937B-F6343F1E6CF7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: Cc: LISP mailing list list Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 18:47:23 -0000 Hello Dino, thanks for taking time to answer these concerns. Authors will work on the revised text to incorporate those points. Anton On Sunday 16 October 2016 22:43, Dino Farinacci 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 >> . >> >> 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. > Thanks for the review Dale. Your comments are outstanding! And your suggestions even better. ;-) > > I am not an author but was involved in the LISP-DDT design early on so I would like to respond to some of your comments. Where I think text should change, I will suggest that to help the authors. To clarify understanding, I will comment inline. > > One of the authors will make the changes. > >> * 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: > Yes, you interpreted the defintion of an extended-EID correctly. It is a multi-tuple entity that has hierarchy so we can delegate any tuple, as well as the tuple itself, downward on the tree. > >> In section 3, definition "XEID-prefix" seems to assume that an >> XEID-prefix will always contain a complete DBID, IID, and AFI. > For a lookup yes. For a delegation, it can be any part of it as I explained above. > >> 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. > Well it is authoriative for everything, by default, but a Map-Referral return code will tell you exactly what it is authoritative for if configured for specficy XEIDs. > >> 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. > Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), it would be the delegation represents all prefixes in all address families. > > We should clarify that in the text. > >> 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. > I think we don’t need to say how its initialized IMO. We should change text here. > >> * 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. > Agree. We should make this change. > >> 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. > Experience has showed us that running parallel mapping databases will be useful. They really don’t need to be numbered or identified because there will be distinct roots and xTRs can connect to one or multiple of them. > > And right now, we do not have an encoding for a DBID that can be sent in a Map-Register or Map-Request. So I am agreeing with you. > >> 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. > Well no, not insane, if we required IID for every register and request, then the XEID would have the same set of tuples for all lookups. Supplying an IID=0 is not wrong or bad semantically and just cost 32-bits in message space. > >> 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. > True. Authors use the reference I put in the latest LCAF draft. That was an IESG comment. So we should get it right. > >> * 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. > Should be fixed in the text. Thanks. > >> * 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. > Well RFC6833 defines the "bottom-half” of the map-server. That is the interface for Map-Registration. A Map-Server is also a DDT-node when there are map-server-peer configuration so a set of map-servers that are authoritative and have registeration state for the same prefix can include themselves as referrals in Map-Referral messages. > >> * 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. > The name “Map-Server” in context to LISP-DDT means that it is a DDT-node at the bottom of the tree with no DDT-node children. It is a DDT-node but one with more functionality, Map-Server functionality according to RFC6833. > >> However, the preceding paragraph assumes that a DDT node is not >> allowed to contain both prefix delegations and ETR registrations. > Correct. > >> 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. > All correct. You interpreted the idea exactly. > >> * Is it really true that two Map Servers that are authoritative for >> the same XEID prefix can contain different sets of ETR registrations? > Typically no. The set of ETRs at a LISP site will register all the ETRs RLOCs for the same EID-prefix. Therefore, each map-server, that all ETRs for that site register to, will have the same EID-prefix-to-RLOC-set mapping. > >> 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? > No, it doens’t have to do that. And it SHOULDN’T that. I can query each referral from a Map-Referral serially or in parallel, only for reachability and robustness reasons. > >> 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. > It is a bit. But leaves out specifics to LISP-DDT because Map-Servers can use any “mapping database transport” system. > >> * 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 > We should have new text to make this more clear. > >> 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. > All good points. Agree. > >> 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. >> >> — > Agree. > >> 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. > Agree. > >> 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. > I think we should have both. > >> 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. > Agree. > >> 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. > The flag is to tell the difference between a Map-Request that is originated by a LISP-site (ITR or PITR) and one that is sent by a Map-Resolver. One generates a Map-Reply and the other generates a Map-Referral. > >> 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. > That is that the typical case though. Look at it as a Map-Request, with DDT-flag set, as a solitication for a Map-Referral. > >> 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! > Correct. > >> 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 > It can work that way. Do you think calling the bit “Request-for-Map-Referral” would be better? > >> 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. > Or we could call the bit “DDT-client-flag”. And still keep the reference to the bit called “D”. > >> 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 > We should say “more specific information”. Where “more-specific” is relative to the xEID-prefix. > >> 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. > True. We should have new text to make this more clear. > >> 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 > No, not architecturally. It receives only Map-Requests with the DDT-bit set to 0. I say no architecturelly because if the map-resolver is also a map-server, then it could receive DDT Map-Requests. But it is acting as a map-server. > > DDT-nodes could also be map-resolvers. Which mean they are part of the delegarion hierarchy but also are configured with DDT-roots to send requests. It all comes down to how a network adminstrator would want to co-locate such functions. > > With the popularity of VMs and containers, the same piece of bare-metal could be both a map-resolver and DDT-node, but from a LISP architecture point of view, they are separate nodes (with separate IP addresses). > >> 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. > DDT-Map-Requests to not get sent to Map-Resolvers and we should make that crystal clear. > >> 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). > Map-Servers configured as a DDT-node is definitely part of DDT because they must send MS-ACK based Map-Referrals. Because if this does not happen, then Map-Resolvers will retransmit and think they have not got to the bottom of the referral tree. > >> 6.1. Action codes >> >> MS-ACK (2): indicates that a replying DDT Map Server received a DDT >> >> s/a replying/the replying/ > Agree. > >> 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. > To be honest, I am questioning the value of “hint” as a reference. Hmm. Let’s see what the authors think about this. > >> 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. > Agree. > >> 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. > We don’t want to add an additional set of comabinations for hints and non-hints. Authors, we should discuss this. > >> 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. > All this is trying to say (and with too many words), is that the referral-set is stored in a Map-Referral as RLOC-records. That is all. > >> 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. > Needs to be fixed in the text. > >> 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. > The signature covers the complete Map-Referral message. If that is not clear, we will make it clear. > >> 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. > It allows the implementation to be more efficient. You build the message once with the correct length include the signature records, run the hash over it. And then fill in the zero bit fields. That way you can then include the referral addresses that are part of the LCAF. > >> Is it a problem that Original Record TTL, Signature Expiration, and >> Signature Inception aren't protected by the signature? > The entire Map-Referral should be covered 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. > See my explanations above. > >> 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. > Agree. > >> 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 > True, in the DDT case as well. > >> 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. > But that isn’t precisely true. Delegations ARE configuration items, in DDT-nodes, all of roots, ddt-nodes, and map-servers. And the cache is dynamically created entries from Map-Referrals from those node’s configuration information. > >> 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 > No, they would be. > >> 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. > We have to simplify this wording. It is more complex than it needs to be. > >> 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 > No, both. Because map-resolvers need to know where to send DDT-Map-Requests and when they get signed Map-Referrals, then need a public key to verify the signature. And the reason is beacuse there is no parent of the root that can give the map-resolver the public-key like the rest of the hierarchy can do. > >> 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. > Yes, yes, yes. > >> 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”. > Really good point. > >> 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”. > Right. > >> 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. > Agree. The Map-Resolver does send a response. If its not documented, we missed it and will add. > >> MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same >> manner >> >> It might be better to say "processes" than "follows”. > Agree. > >> 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. > You are absolutely right. There needs to be a complete example of the “day in the life of a Map-Request” when the Map-Resolver has nothing cached and the ITR and ETR are not DDT-clients. That is the typical use-case that has been and will continue to be deployed. > >> 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. > LISP-SEC information is in the Map-Request from the ITR, transported in the DDT-Map-Request so an ETR can get the LISP-SEC information in the Map-Request to then return LISP-SEC in the *Map-Reply*. > > The Map-Server only sends Map-Replies when it is configured to proxy-reply and the ETR is not in the loop here. And it would fill in the same LISP-SEC information the ETR would because the registration information is the same as the database entry info the ETR has stored. > >> 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”. > It means the DDT-Map-Request went all the way to the map-server, it has a a configure LISP site entry and the ETRs have not registered (yet). > >> 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 > A response is ALWAYs returned in LISP-DDT. The only time it can’t is when a Map-Request cannot get to where its going or the Map-Referral cannot get back to the DDT-client source. And that is the only case we call a “timeout”. > >> 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. > Agree. We should have new text to make this more clear. > >> 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: > Yes, because each parent points to 2 children. > >> +---------------------+ +---------------------+ >> | 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/ > Agree. > >> 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. > Agree. > >> 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. > Really good point. I definitely agree. > >> 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. > It should yes. > >> 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. > An RLOC record contains LCAF type 11 with the RLOC/address of the referral and key material. > >> 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. > Agree. > >> 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. > We have referred to LISP-DDT-SEC to mean the public/private key signing of Map-Referral messages. That is what the reference to DDT security could mean. But this section could be confidentiality support as well. > >> 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). > Should be normative since we are about to publish the LCAF RFC. > >> [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, >> > 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, . >> >> 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. > Agree. > >> Dale > Thanks again for the really detailed comments. > > Dino > > > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Nov 1 11:51:36 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC71293F5; Tue, 1 Nov 2016 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4OHO-DpYqaD; Tue, 1 Nov 2016 11:51:32 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08BF129874; Tue, 1 Nov 2016 11:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1654; q=dns/txt; s=iport; t=1478026292; x=1479235892; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4rK8HZYiyUoXaV+5PIw+ZoSRec+Q+9AArfesGpDjDkI=; b=OOW5OmjZAZ2LRkCX3LL2tqLena1NKvAU35v/WozNGSD/j5pAdLGt97oi IH9EAhg4th90zZSYTu63FIKxVhbLUKVsulJYW5J85JvI3qDLo0gcHHyjb t7wAM9zHSYUTzIND9JedKRBMQZtUjObsoOwP2UHtp/OOVqMox+JUPyGZz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgCt4xhY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAXcDJ1KNNpcBkjaCD4IHKIV6AoJSFAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQQjFUEQCxgCAiYCAlcGAQwIAQGIUA6rBI0BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYEHhTaBfYJYhBkRAYMgglwFiEaLdoVehjGKBIFuhG6DF4YTjROEBB4?= =?us-ascii?q?2UgYIg1iBPD00AYUiDRcHgg4BAQE?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="689335444" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 18:51:30 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uA1IpTA6015044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2016 18:51:29 GMT To: Stephen Farrell , The IESG References: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: <74bb00ca-b694-95ea-48a8-4241e3eb7e38@cisco.com> Date: Tue, 1 Nov 2016 19:51:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 18:51:34 -0000 Hello Stephen, thanks for your comment. Existing DDT implementations are already using RSA-SHA1, so we cannot simply replace it with RSA-SHA256. But we should be able to add the latter as another signing algorithm. Authors will take in your comments in the next revision of the draft. Anton On Thursday 27 October 2016 14:44, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-lisp-ddt-08: 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-ddt/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > 6.4.1: RSA-SHA1 is not the right choice today, shouldn't > this be RSA-SHA256? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 6.4.1: Can you clarify what bits are signed? I'm not > quite sure from the description given - you can have > more than one signature but you say the the "entire > record" is covered. > > - Section 8: Where's signature validation in the > pseudo-code? > > From nobody Tue Nov 1 12:05:20 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D741298D0; Tue, 1 Nov 2016 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NaDh50Pt5Nu; Tue, 1 Nov 2016 12:05:14 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7D4129969; Tue, 1 Nov 2016 12:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1824; q=dns/txt; s=iport; t=1478027066; x=1479236666; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=H8wPRsNvjkArsZ5xF8cT65Cj66Jg66VLWE163A0R/w4=; b=Pyjl5xTTsoOjhUgJxGmNLWD0U/qwwomLRyZ64UJlGYqBWowJWjy8Lgwa Kix4mkmKqfyvgwLR1P2ds3aJLiC16z26JX8kzo+iJRCz/lckWawNsOkEN 9O1CDRMjWJ+12rb2SNyjBuSwveGibe5u32+TiZUzXsNNlcL1etgIur+zj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgDU5hhY/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMqAQEBAQF3AydSjTaXAZI2gg+CByiFegKCUhQBAgEBAQEBAQF?= =?us-ascii?q?iKIRiAQEEIw8BBUEQCw4KAgImAgJXBgEMCAEBiFAOqxOMfwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWBB4U2gX0IglCEGQcKAYMgglwFiEaRVIYxigSBboRugxeGE40?= =?us-ascii?q?ThAQeNlIGCIUUPTQBhS+CLAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="649618009" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 19:04:23 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uA1J4Nee020000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2016 19:04:23 GMT To: Mirja Kuehlewind , The IESG References: <147756279870.18880.16779109803016660833.idtracker@ietfa.amsl.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: <30d35695-5683-30f3-f2d3-28739a1bbf86@cisco.com> Date: Tue, 1 Nov 2016 20:04:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147756279870.18880.16779109803016660833.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-lisp-ddt-08=3A_=28with_COMMENT=29?= X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 19:05:15 -0000 Hello Mirja, thanks for your comment. Since LISP/DDT was conceived to be used on the public Internet security concerns are very important and were taken very seriously. Authors believe that the trust delegation scheme specified in the document provides very good mechanism to verify authenticity of DDT messages. The system obviously remains potentially vulnerable to (d)DOS attacks overloading DDT nodes with non-authenticated requests. Most of security concerns are inherited from LISP-SEC and are being discussed in the corresponding draft. Authors are planning to enhance security section of the draft in the next revision, mostly to clarify calculation and verification of signatures. Anton On Thursday 27 October 2016 12:06, Mirja Kuehlewind wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-lisp-ddt-08: No Objection > > 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-ddt/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Would it be worth it to potentially think about/document potential > attacks against this system? I didn't think myself about how such an > attack could look like but given that location and identity are potential > sensitive data it might be worth it... > > From nobody Tue Nov 1 12:10:12 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90791298AC; Tue, 1 Nov 2016 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8ManuN4StW2; Tue, 1 Nov 2016 12:10:04 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8488E129872; Tue, 1 Nov 2016 12:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1615; q=dns/txt; s=iport; t=1478027402; x=1479237002; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xQ1DNSY9/T4Ev6RmIUugUP3zZg5tC2YqnaPH+RSB6pA=; b=gOQGaoekJsEuH3OWJFW+vmxDh7Dbf6Hz/pgcSVTPziOQKBvAI/MW17Cm Ymjbj4DxJUYfcR47zSFmuc2z/oUAMBCYnIVmJsfiC2NwuOXxbuteOZueh +ha6UV9yjmFNqUTIVUY4WmeGt+t+zRGYePOZQ08I58UIZC5CALO8aX5Ds Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAgD85xhY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoBAQEBAXcDJ1KNNpcBkjaCD4IHKIV6AoJSFAECAQEBAQEBAWI?= =?us-ascii?q?ohGIBAQQjDwEFQRALGAICJgICVwYBDAgBAYhQDqscjH8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFgQeFNoF9CIJQhBkRAYMgglwFiEaRVIYxigSBboRugxeGE40ThAQ?= =?us-ascii?q?eNlIGCIUUPTQBhS+CLAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,580,1473120000"; d="scan'208";a="649618059" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2016 19:09:59 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uA1J9wo4006093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Nov 2016 19:09:59 GMT To: Jari Arkko , The IESG References: <147757639208.24578.6861441364742553634.idtracker@ietfa.amsl.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: Date: Tue, 1 Nov 2016 20:09:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147757639208.24578.6861441364742553634.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: Cc: lisp-chairs@ietf.org, worley@ariadne.com, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Jari Arkko's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 19:10:06 -0000 Hello Jari, authors are planning to work on new draft revision to clarify dubious and ambiguous pieces of text brought up by Dale's comments. Anton On Thursday 27 October 2016 15:53, Jari Arkko wrote: > Jari Arkko has entered the following ballot position for > draft-ietf-lisp-ddt-08: 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-ddt/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for this draft. > > I plan to recommend its approval, but first I would like to ensure that > the issues raised by Dale Worley in his Gen-ART review are addressed > satisfactorily and in consultation with the working group, to ensure that > the document is as clear as possible. Specifically, the questions about > XEIDs and the definition of a peer and a DDT node at least need to be > worked through. (I’m not necessarily asking for text changes, but looking > for convergence in the discussion so that we are on the same page about > what is meant. And I see the discussion is already ongoing -- thanks for > that.) > > > > From nobody Tue Nov 1 13:32:26 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AB81299E9; Tue, 1 Nov 2016 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpNyX0N9vwez; Tue, 1 Nov 2016 13:32:18 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id A2D4A1299B2; Tue, 1 Nov 2016 13:32:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E06DF2CEF7; Tue, 1 Nov 2016 22:32:15 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rraKpSwKhtUJ; Tue, 1 Nov 2016 22:32:15 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 594C32CED2; Tue, 1 Nov 2016 22:32:15 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_068855DC-49AA-452B-AD1C-6B48F088CCED"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Tue, 1 Nov 2016 22:32:15 +0200 Message-Id: References: <147757639208.24578.6861441364742553634.idtracker@ietfa.amsl.com> To: Anton Smirnov X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-ddt@ietf.org, worley@ariadne.com, The IESG Subject: Re: [lisp] Jari Arkko's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 20:32:20 -0000 --Apple-Mail=_068855DC-49AA-452B-AD1C-6B48F088CCED Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks! Jari --Apple-Mail=_068855DC-49AA-452B-AD1C-6B48F088CCED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYGPvPAAoJEM80gCTQU46qyBoQAK4lo5Okjs4o1qlAJGlHeNpD EzfWqDa16d+n3HnBkFpTJKoiGhf7wFFni/AjEe4v4ldudryNsSgxUUYWdGs3u1ON kfnGGAGdi2ZGh7xVm3un9W2ByCSJpwHpq8VED+jB8AbVGcrkSBibI0wEHZZcQWas HdNtrzIWTj0OfOfIN3JndhFILDD+vOEFxMZKn2HZGEfPfZhbvhXBX+Qeflly1xse jOQxaiQBztcGFRlSNGMSqWa5X+pJPPnuLCr2/cN6ftXv/X1waEdstrYOAeTRFJBz 7j4N1WCctJX8diDzzKTrc1MBpH6pDBdkI+erwlwOMFGtfWjh3/Np2qL5AKR7lVaS WEI+VPyvN0Q4FIdDtIeEUo93+rszBGLbmzX0/1Ybw69WiCg6fWlKb3BDjSTBcFCm SdBf37ZaDS3rBhQCKpWyk+JPSQe7BfvpwAV2UnKNAIwzAvmEYe7r8gatulI6P2oj /dZNPGbKr0zFHyiGmnaXQacwRLdKixfUoZQYC/npJevHzyyOmt67JwzW7x+HyDwd ZLQaJNRgWlpAkgOASIkJed5aMrgoRyAldGIGCK9VM7Cdh3tjILdICjAmY+fL+B+i qXufTWC4cdwlyRhI2YfFeGNHr4pBD0fY+cLFIRPPRXEgMWJUswZIe0UAbGBaApY+ 9tWSu0ZzGaJUnag1jnYn =o3jT -----END PGP SIGNATURE----- --Apple-Mail=_068855DC-49AA-452B-AD1C-6B48F088CCED-- From nobody Tue Nov 1 14:09:15 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E81299F8; Tue, 1 Nov 2016 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLY7dVWxtHV9; Tue, 1 Nov 2016 14:09:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1215A1299E3; Tue, 1 Nov 2016 14:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4BB53BE4C; Tue, 1 Nov 2016 21:09:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtQUM2F6lvW8; Tue, 1 Nov 2016 21:09:00 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46408BE38; Tue, 1 Nov 2016 21:09:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478034540; bh=cV0jAR72sOHLudbYGY8ge5Xdi9coMP36Q3SY9N0gW6o=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gKU0z982GvEBBjldHTiBHjWgGjoCr1zL8Ic/SuHRqfiBElr1CS5TWVPIUkbw6oMdZ Nf1t0MPEvwYiXF975F9wMGuSGbKnWFAwDp+Tw170kFQiH62BY5u/4QGz7Y9MOqAvAe f3W46Y1cJG2jZVW7IaOn98/x4z57rcHQyDUNyfyM= To: Anton Smirnov , The IESG References: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> <74bb00ca-b694-95ea-48a8-4241e3eb7e38@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <14cddbee-ebf4-6eeb-e772-4ef6f550f28b@cs.tcd.ie> Date: Tue, 1 Nov 2016 21:09:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <74bb00ca-b694-95ea-48a8-4241e3eb7e38@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000308030301080203020401" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:09:08 -0000 This is a cryptographically signed message in MIME format. --------------ms000308030301080203020401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/11/16 18:51, Anton Smirnov wrote: > Hello Stephen, >=20 > thanks for your comment. >=20 > Existing DDT implementations are already using RSA-SHA1, so we cannot= > simply replace it with RSA-SHA256. But we should be able to add the > latter as another signing algorithm. Really? The sha-1 weaknesses for use in signatures were found and documented in an RFC in 2005. [1] We published an RFC attempting to tidy up remaining loose ends related to sha1 for signatures in 2011. [2] Asking for rsa-sha1 now is really very far behind the state of the art. But are you talking implementations or deployments here? If mostly the former then I think you ought remove rsa-sha1 entirely and replace with rsa-sha256. That is a trivial code change and I can see no justification for not making that change. If you are talking about existing deployments please provide the argument as to why those are such that we should publish an RFC that calls for use of an obsolete signature algorithm 11 years after the initial crypto weaknesses were documented in the IETF. If there are good arguments for that a) I'll be surprised, and b) my plan would be to ask for advice from the security area - I don't think we've hit this case before where an experimental RFC wants to use such a thoroughly obsolete signature algorithm, one that would never be ok in a standards track RFC and one where it's really easy to do the right thing instead. Cheers, S. [1] https://tools.ietf.org/html/rfc4270 [2] https://tools.ietf.org/html/rfc6194 >=20 > Authors will take in your comments in the next revision of the draft= =2E >=20 > Anton >=20 > On Thursday 27 October 2016 14:44, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-lisp-ddt-08: 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 thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> 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-ddt/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> 6.4.1: RSA-SHA1 is not the right choice today, shouldn't >> this be RSA-SHA256? >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - 6.4.1: Can you clarify what bits are signed? I'm not >> quite sure from the description given - you can have >> more than one signature but you say the the "entire >> record" is covered. >> >> - Section 8: Where's signature validation in the >> pseudo-code? >> >> >=20 --------------ms000308030301080203020401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDEy MTA5MDBaMC8GCSqGSIb3DQEJBDEiBCBcZJoWLPVR+2ha8Xkdi3YlIJd9L5G/TFJ7ZXK+Np5l SjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCNA+WkUH8IorR961qwcObAuQM81Pk677nqGi9nuuFQINEvhYnTZgxK 5qFHJAPl4V1L20IEzZr7zY3H+RKmpE3d1DFNqr2m9HQVOnZAQtVN4fSspsGAjNcvUOW1q3hp K/lw9/oHtdSjmALx+qlNOJ0LeWGfmWJ/TLmDG25cMXkOdW4NiLfHCgT0RtJQah1Cyu1sKpT9 rhjapPly3zeDHG5Soh9OcplcKa4CCYYuxV3Jj5XlWChGOpeaC+TkfMT1eWXk4RTo1PsvpOKg h8O9i8bNaiz7Q4ebje8BVsgELEBWFwHfR07nySjPWXl8v8RswWj4urR6TuSB0CTn/+E3NlMS AAAAAAAA --------------ms000308030301080203020401-- From nobody Tue Nov 1 14:55:21 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACC61295CD for ; Tue, 1 Nov 2016 14:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTjiHELCng-y for ; Tue, 1 Nov 2016 14:55:14 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528CF1298C0 for ; Tue, 1 Nov 2016 14:55:14 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id n85so101488271pfi.1 for ; Tue, 01 Nov 2016 14:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yTYP75lE1cUogymaAXSChzzV88vSf4oiZIqelXPd3Lc=; b=cVMcd5hj6wOVEBFkYjaLuU9MiJE5SqFVAAoGAkDfuDS/GJSdSPVaiksDDjeKFjLgxI 6rfYyekGgmIkNScSNtxNpOcfnLzDsw1O4wMAhi3DS+o0Ulcu480etRU4KzqBsTtNFPUj RTTwjGcAw/hd2I8AHQT/PqRTvvb2EBC3uwEIQ9/XnM7X8C+7Gw/q8oES3tZA31Q2JpSa frYMuSxK7BGiLc+bB/e3jCEj5MPpIP7r6UCVRXJ7oO/wwp762plECYldgsbVp89aYGNu JcQzYu83ppG9Z0uMQKXUAffGs5mPL+m9zt8FfD+0ogGtN71wCu5NBN4jItEmV7+iQorl FtAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yTYP75lE1cUogymaAXSChzzV88vSf4oiZIqelXPd3Lc=; b=jYRunFmvaSlrMh7E61qJi1gm4Rjs6K5WmPxwYy0IdaioFwOMbjtsZ7PC0UgmmuZ52N DTvmjJs9LbAw7pVNDU8NqknI3jZ9Csi4Nas/wI+zZQ+V0S4Gy1bnYGgJhxHl+DqAIK0N 7cd6PjDfz9HoI9R+sNgT5w5Ofa9uAOh99SqLLsVDTCSRsdjyXX802KRqI5szfmSPl0Ly LPWUcFqAtJLyqNGifPm10Ukk38J99snX7eorI4ADie8FkLQn4RgzPQpRNrt7k2yxtPWE ZszTjb6Pr87EqKaphT68uRAEDtDRFFMXkVTfTK+RqlPb22MqtvbDNZ3NC6c7pH4yvidx qV6g== X-Gm-Message-State: ABUngvdevfKRI8XpVEUOaGK49/tIu8ii5jVeoGa+2gHCd18rkeI7hwh7dGdq+YdzmtSeDA== X-Received: by 10.99.196.70 with SMTP id m6mr342922pgg.118.1478037312344; Tue, 01 Nov 2016 14:55:12 -0700 (PDT) Received: from dino-macbook.lan (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id j192sm44320017pfc.60.2016.11.01.14.55.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Nov 2016 14:55:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: Date: Tue, 1 Nov 2016 14:55:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0099C88F-59F0-4201-9518-214D525342C4@gmail.com> References: <87bmym4cyp.fsf@hobgoblin.ariadne.com> <50795FAC-6560-4F02-937B-F6343F1E6CF7@gmail.com> To: Anton Smirnov X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "Dale R. Worley" , LISP mailing list list Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 21:55:18 -0000 Great to hear. Is the goal to publish the new draft on Monday of IETF = week? Dino > On Nov 1, 2016, at 11:47 AM, Anton Smirnov wrote: >=20 > Hello Dino, >=20 > thanks for taking time to answer these concerns. Authors will work = on the revised text to incorporate those points. >=20 > Anton >=20 > On Sunday 16 October 2016 22:43, Dino Farinacci 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. >>>=20 >>> For more information, please see the FAQ at >>> . >>>=20 >>> 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 >>>=20 >>> Summary: This draft is on the right track but has open issues, >>> described in the review. >> Thanks for the review Dale. Your comments are outstanding! And your = suggestions even better. ;-) >>=20 >> I am not an author but was involved in the LISP-DDT design early on = so I would like to respond to some of your comments. Where I think text = should change, I will suggest that to help the authors. To clarify = understanding, I will comment inline. >>=20 >> One of the authors will make the changes. >>=20 >>> * 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: >> Yes, you interpreted the defintion of an extended-EID correctly. It = is a multi-tuple entity that has hierarchy so we can delegate any tuple, = as well as the tuple itself, downward on the tree. >>=20 >>> In section 3, definition "XEID-prefix" seems to assume that an >>> XEID-prefix will always contain a complete DBID, IID, and AFI. >> For a lookup yes. For a delegation, it can be any part of it as I = explained above. >>=20 >>> In section 4.2.1: >>>=20 >>> The root DDT node is the logical "top" of the database hierarchy: >>> DBID=3D0, IID=3D0, AFI=3D0, EID-prefix=3D0/0. >>>=20 >>> But really, the condition of a root node is that it's authoritative >>> for the *empty* XEID-prefix. >> Well it is authoriative for everything, by default, but a = Map-Referral return code will tell you exactly what it is authoritative = for if configured for specficy XEIDs. >>=20 >>> 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. >> Right, if a delegation is configured with solely the 2-tuple (DBID=3D0,= IID=3D0), it would be the delegation represents all prefixes in all = address families. >>=20 >> We should clarify that in the text. >>=20 >>> 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: >>>=20 >>> the "referral XEID-prefix" is also initialized to the null value >>> since no referral has yet been received. >> I think we don=E2=80=99t need to say how its initialized IMO. We = should change text here. >>=20 >>> * 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. >> Agree. We should make this change. >>=20 >>> 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. >> Experience has showed us that running parallel mapping databases will = be useful. They really don=E2=80=99t need to be numbered or identified = because there will be distinct roots and xTRs can connect to one or = multiple of them. >>=20 >> And right now, we do not have an encoding for a DBID that can be sent = in a Map-Register or Map-Request. So I am agreeing with you. >>=20 >>> IID is presumably expected to be zero except when VPNs are used. = (see >>> definition "Extended EID (XEID)") >>>=20 >>> 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. >> Well no, not insane, if we required IID for every register and = request, then the XEID would have the same set of tuples for all = lookups. Supplying an IID=3D0 is not wrong or bad semantically and just = cost 32-bits in message space. >>=20 >>> 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. >> True. Authors use the reference I put in the latest LCAF draft. That = was an IESG comment. So we should get it right. >>=20 >>> * 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. >> Should be fixed in the text. Thanks. >>=20 >>> * 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. >> Well RFC6833 defines the "bottom-half=E2=80=9D of the map-server. = That is the interface for Map-Registration. A Map-Server is also a = DDT-node when there are map-server-peer configuration so a set of = map-servers that are authoritative and have registeration state for the = same prefix can include themselves as referrals in Map-Referral = messages. >>=20 >>> * 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. >> The name =E2=80=9CMap-Server=E2=80=9D in context to LISP-DDT means = that it is a DDT-node at the bottom of the tree with no DDT-node = children. It is a DDT-node but one with more functionality, Map-Server = functionality according to RFC6833. >>=20 >>> However, the preceding paragraph assumes that a DDT node is not >>> allowed to contain both prefix delegations and ETR registrations. >> Correct. >>=20 >>> 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. >> All correct. You interpreted the idea exactly. >>=20 >>> * Is it really true that two Map Servers that are authoritative for >>> the same XEID prefix can contain different sets of ETR = registrations? >> Typically no. The set of ETRs at a LISP site will register all the = ETRs RLOCs for the same EID-prefix. Therefore, each map-server, that all = ETRs for that site register to, will have the same = EID-prefix-to-RLOC-set mapping. >>=20 >>> 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? >> No, it doens=E2=80=99t have to do that. And it SHOULDN=E2=80=99T = that. I can query each referral from a Map-Referral serially or in = parallel, only for reachability and robustness reasons. >>=20 >>> 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. >> It is a bit. But leaves out specifics to LISP-DDT because Map-Servers = can use any =E2=80=9Cmapping database transport=E2=80=9D system. >>=20 >>> * 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 >> We should have new text to make this more clear. >>=20 >>> 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. >> All good points. Agree. >>=20 >>> 1. Introduction >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> 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. >>>=20 >>> =E2=80=94 >> Agree. >>=20 >>> It >>> also provides delegation information to Map Resolvers, which use = the >>> information to locate EID-to-RLOC mappings. >>>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>> and approximately all uses of "Map Resolver" should be changed to = "DDT >>> client". >>>=20 >>> LISP-DDT defines a new device type, the DDT node, that is = configured >>> as authoritative for one or more XEID-prefixes. >>>=20 >>> 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. >> Agree. >>=20 >>> 3. Definition of Terms >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> These can be simplified by moving the details of the XEID format and >>> the values of the fields into separate paragraphs (as discussed >>> above). >>>=20 >>> DDT node: a network infrastructure component responsible for >>> specific XEID-prefix and for delegation of more-specific sub- >>> prefixes to other DDT nodes. >>>=20 >>> 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)". >>>=20 >>> 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. >>>=20 >>> 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. >> I think we should have both. >>=20 >>> 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 ... >>>=20 >>> Given the importance of Map-Request messages, it might be worth >>> mentioning that they are defined in RFC 6830. >> Agree. >>=20 >>> 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. >> The flag is to tell the difference between a Map-Request that is = originated by a LISP-site (ITR or PITR) and one that is sent by a = Map-Resolver. One generates a Map-Reply and the other generates a = Map-Referral. >>=20 >>> 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. >> That is that the typical case though. Look at it as a Map-Request, = with DDT-flag set, as a solitication for a Map-Referral. >>=20 >>> Also, the definition of the flag in section 5 is awkward: >>>=20 >>> 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]. >>>=20 >>> 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! >> Correct. >>=20 >>> 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 >> It can work that way. Do you think calling the bit = =E2=80=9CRequest-for-Map-Referral=E2=80=9D would be better? >>=20 >>> 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. >> Or we could call the bit =E2=80=9CDDT-client-flag=E2=80=9D. And still = keep the reference to the bit called =E2=80=9CD=E2=80=9D. >>=20 >>> 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; >>>=20 >>> 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 >> We should say =E2=80=9Cmore specific information=E2=80=9D. Where = =E2=80=9Cmore-specific=E2=80=9D is relative to the xEID-prefix. >>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> 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. >> True. We should have new text to make this more clear. >>=20 >>> 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. >>>=20 >>> 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 >> No, not architecturally. It receives only Map-Requests with the = DDT-bit set to 0. I say no architecturelly because if the map-resolver = is also a map-server, then it could receive DDT Map-Requests. But it is = acting as a map-server. >>=20 >> DDT-nodes could also be map-resolvers. Which mean they are part of = the delegarion hierarchy but also are configured with DDT-roots to send = requests. It all comes down to how a network adminstrator would want to = co-locate such functions. >>=20 >> With the popularity of VMs and containers, the same piece of = bare-metal could be both a map-resolver and DDT-node, but from a LISP = architecture point of view, they are separate nodes (with separate IP = addresses). >>=20 >>> 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. >> DDT-Map-Requests to not get sent to Map-Resolvers and we should make = that crystal clear. >>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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). >> Map-Servers configured as a DDT-node is definitely part of DDT = because they must send MS-ACK based Map-Referrals. Because if this does = not happen, then Map-Resolvers will retransmit and think they have not = got to the bottom of the referral tree. >>=20 >>> 6.1. Action codes >>>=20 >>> MS-ACK (2): indicates that a replying DDT Map Server received a = DDT >>>=20 >>> s/a replying/the replying/ >> Agree. >>=20 >>> 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. >>>=20 >>> 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. >> To be honest, I am questioning the value of =E2=80=9Chint=E2=80=9D as = a reference. Hmm. Let=E2=80=99s see what the authors think about this. >>=20 >>> 6.3. Incomplete flag >>>=20 >>> 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. >>>=20 >>> 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". >>>=20 >>> 6.4. Map-Referral Message Format >>>=20 >>> 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. >> Agree. >>=20 >>> 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. >>>=20 >>> 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. >> We don=E2=80=99t want to add an additional set of comabinations for = hints and non-hints. Authors, we should discuss this. >>=20 >>> 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]. >>>=20 >>> This paragraph doesn't make sense in this context. The terms "Loc", >>> "keys", "LCAF", "Security material" are all undefined in this = context. >>>=20 >>> 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. >>>=20 >>> 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. >> All this is trying to say (and with too many words), is that the = referral-set is stored in a Map-Referral as RLOC-records. That is all. >>=20 >>> 6.4.1. SIG section >>>=20 >>> Sig Length: The length of the Signature field. >>>=20 >>> Is this measured in bytes? >>>=20 >>> 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. >> Needs to be fixed in the text. >>=20 >>> 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. >> The signature covers the complete Map-Referral message. If that is = not clear, we will make it clear. >>=20 >>> 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. >> It allows the implementation to be more efficient. You build the = message once with the correct length include the signature records, run = the hash over it. And then fill in the zero bit fields. That way you can = then include the referral addresses that are part of the LCAF. >>=20 >>> Is it a problem that Original Record TTL, Signature Expiration, and >>> Signature Inception aren't protected by the signature? >> The entire Map-Referral should be covered by the signature. >>=20 >>> 7.1.1. Match of a delegated prefix (or sub-prefix) >>>=20 >>> If the delegation is known to be a DDT Map Server, >>>=20 >>> 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. >> See my explanations above. >>=20 >>> 7.1.2. Missing delegation from an authoritative prefix >>>=20 >>> 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. >>>=20 >>> It would be a bit clearer if "the least-specific XEID-prefix" was >>> changed to "the least-specific prefix of the XEID". >>>=20 >>> 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. >>>=20 >>> 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. >> Agree. >>=20 >>> 7.3. DDT Map Resolver >>> 7.3.1. Queuing and sending DDT Map-Requests >>>=20 >>> 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 >> True, in the DDT case as well. >>=20 >>> 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. >> But that isn=E2=80=99t precisely true. Delegations ARE configuration = items, in DDT-nodes, all of roots, ddt-nodes, and map-servers. And the = cache is dynamically created entries from Map-Referrals from those = node=E2=80=99s configuration information. >>=20 >>> 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: >>>=20 >>> The referral cache is initially populated with one or more >>> statically-configured entries; >>>=20 >>> Similarly this is a structural statement about the cache: >>>=20 >>> A DDT Map Resolver is not absolutely required to cache referrals, >>> but it doing so decreases latency and reduces lookup delays. >>>=20 >>> -- >>>=20 >>> 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. >>>=20 >>> 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 >> No, they would be. >>=20 >>> 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. >> We have to simplify this wording. It is more complex than it needs to = be. >>=20 >>> 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 >> No, both. Because map-resolvers need to know where to send = DDT-Map-Requests and when they get signed Map-Referrals, then need a = public key to verify the signature. And the reason is beacuse there is = no parent of the root that can give the map-resolver the public-key like = the rest of the hierarchy can do. >>=20 >>> 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. >> Yes, yes, yes. >>=20 >>> 7.3.2. Receiving and following referrals >>>=20 >>> If the maximum number of retransmissions has occurred and all = RLOCs >>> have been tried, then the pending request list entry is dequeued. >>>=20 >>> 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". >>>=20 >>> 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=E2=80=9D. >> Really good point. >>=20 >>> 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=E2=80=9D. >> Right. >>=20 >>> 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. >> Agree. The Map-Resolver does send a response. If its not documented, = we missed it and will add. >>=20 >>> MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the = same >>> manner >>>=20 >>> It might be better to say "processes" than "follows=E2=80=9D. >> Agree. >>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>> 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. >> You are absolutely right. There needs to be a complete example of the = =E2=80=9Cday in the life of a Map-Request=E2=80=9D when the Map-Resolver = has nothing cached and the ITR and ETR are not DDT-clients. That is the = typical use-case that has been and will continue to be deployed. >>=20 >>> 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. >> LISP-SEC information is in the Map-Request from the ITR, transported = in the DDT-Map-Request so an ETR can get the LISP-SEC information in the = Map-Request to then return LISP-SEC in the *Map-Reply*. >>=20 >> The Map-Server only sends Map-Replies when it is configured to = proxy-reply and the ETR is not in the loop here. And it would fill in = the same LISP-SEC information the ETR would because the registration = information is the same as the database entry info the ETR has stored. >>=20 >>> 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. >>>=20 >>> I think "non-registered XEID-prefix" is meant to mean = "least-specific >>> prefix of the XEID for which no registrations exist=E2=80=9D. >> It means the DDT-Map-Request went all the way to the map-server, it = has a a configure LISP site entry and the ETRs have not registered = (yet). >>=20 >>> 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. >>>=20 >>> It seems like a poor design to return no response. Is there not = some >> A response is ALWAYs returned in LISP-DDT. The only time it can=E2=80=99= t is when a Map-Request cannot get to where its going or the = Map-Referral cannot get back to the DDT-client source. And that is the = only case we call a =E2=80=9Ctimeout=E2=80=9D. >>=20 >>> sort of "server failure" response that can be returned to the DDT >>> client? >>>=20 >>> 8. Pseudo Code and Decision Tree diagrams >>>=20 >>> 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. >> Agree. We should have new text to make this more clear. >>=20 >>> 9. Example topology and request/referral following >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Are lines in the diagram intended to cross? If so, they could be >>> clarified as: >> Yes, because each parent points to 2 children. >>=20 >>> +---------------------+ +---------------------+ >>> | 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| >>> +---------------------------+ = +---------------------------+ >>>=20 >>>=20 >>> 10. Securing the database and message exchanges >>>=20 >>> 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. >>>=20 >>> s/the XEID-prefix/an XEID-prefix/ >> Agree. >>=20 >>> But the first sentence doesn't say the same thing as the second >>> sentence. Better would be >>>=20 >>> 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. >> Agree. >>=20 >>> 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. >> Really good point. I definitely agree. >>=20 >>> 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. >>>=20 >>> 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. >> It should yes. >>=20 >>> 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. >> An RLOC record contains LCAF type 11 with the RLOC/address of the = referral and key material. >>=20 >>> 11. Open Issues and Considerations >>>=20 >>> o Management of the DDT Map Resolver referral cache, in = particular, >>> detecting and removing outdated entries. >>>=20 >>> 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. >> Agree. >>=20 >>> 13. Security Considerations >>>=20 >>> 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. >>>=20 >>> This sentence is obscure, because "DDT security" is not defined >>> anywhere, and there seems to be no optional security mechanism >>> described in the draft. >> We have referred to LISP-DDT-SEC to mean the public/private key = signing of Map-Referral messages. That is what the reference to DDT = security could mean. But this section could be confidentiality support = as well. >>=20 >>> 14.2. Informative References >>>=20 >>> [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. >>>=20 >>> 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). >> Should be normative since we are about to publish the LCAF RFC. >>=20 >>> [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, >>> >> abs_all.jsp?arnumber=3D5586446>. >>>=20 >>> This reference is not referenced. >>>=20 >>> [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, . >>>=20 >>> 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. >> Agree. >>=20 >>> Dale >> Thanks again for the really detailed comments. >>=20 >> Dino >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Wed Nov 2 09:02:12 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6361296BC; Wed, 2 Nov 2016 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-paristech.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqeTSLydWNNL; Wed, 2 Nov 2016 09:02:08 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) by ietfa.amsl.com (Postfix) with ESMTP id 057461296B8; Wed, 2 Nov 2016 09:02:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id E3E74100B43; Wed, 2 Nov 2016 17:02:06 +0100 (CET) Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vJ-xgzaFDFlY; Wed, 2 Nov 2016 17:02:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 0016E100B4B; Wed, 2 Nov 2016 17:02:04 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy110.enst.fr 0016E100B4B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1478102525; bh=0moeDat54a82ijZjouG4G2q6/I3qURKKKEEgp4sehSE=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=CpOSqqyWUYmrppufsLjNz/9d/BoSa4j/VcQ6sAa00EtYVV7DZ5IXJuP0gl7HsuqhA ivdMaZTGNcL0eB6aBqpbkAIOhUbtMx6QStg5SiLDsOFbg1P568NdjTMf9ca7WeCR6M JAA1mToXMuv9W8XB1hp7Lmn+Jfk/AVkUeyDJ4Urg= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MBRJA9hvm5p6; Wed, 2 Nov 2016 17:02:04 +0100 (CET) Received: from dhcp164-48.enst.fr (dhcp164-48.enst.fr [137.194.165.48]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 9BBDF100B43; Wed, 2 Nov 2016 17:02:04 +0100 (CET) From: Luigi Iannone Message-Id: <204F0A89-BEB8-4BDF-A363-4AABDBF4E262@telecom-paristech.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_679F300A-EE9E-4682-B138-1CFC6DC543A1" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 2 Nov 2016 17:02:04 +0100 In-Reply-To: To: Fabio Maino References: <8204baa6-8cbd-83b3-aa88-dc3ba16c5a33@cisco.com> <38FE74C1-A8F3-4A92-B575-CC5CF4E249D8@telecom-paristech.fr> <37a920e9-b1aa-33c1-6321-e24937bc6c8d@cisco.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, Damien Saucez , LISP mailing list list Subject: Re: [lisp] LISP-SEC review (finally) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:02:11 -0000 --Apple-Mail=_679F300A-EE9E-4682-B138-1CFC6DC543A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fabio, I went through the last version of the document. I still think that in a few place SHOULD should be replaced by MUST. But = it is just my point of view. You can leave SHOULD. There are just few residual issues: - Introduction: The second sentence is not coherent with the first one. = The concept of EID-to-RLOC mappings as not been introduced so starting = the sentence with =E2=80=9CThese EID-to-RLOC mapping s=E2=80=A6=E2=80=9D = is pretty unclear. I would suggest you add another sentence. - Section 7 IANA Considerations: For almost all of the registries the = value =E2=80=9C0=E2=80=9D has a special meaning that this demo is = defining, hence the =E2=80=9Cdefined in=E2=80=9D field should state = =E2=80=9Cthis memo=E2=80=9D - - Section 7 IANA Considerations: The section is not yet 5226 = compliant. More specifically, you have to state for each registry how = new values are allocated (e.g. FCFS, expert review, etc..) Check again the nits: Checking nits according to http://www.ietf.org/id-info/checklist : = --------------------------------------------------------------------------= -- =3D=3D There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they = should be changed. Checking references for intended status: Experimental = --------------------------------------------------------------------------= -- =3D=3D Missing Reference: 'RFC4634' is mentioned on line 840, but not = defined ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234) The above nits reminds me of another issue that the IESG will certainly = raise: can we have all the examples in IPv6 only? The latest directives are that either you use both v4 and v6 or v6-only, = but NOT v4-only. Thanks ciao L. > On 27 Oct 2016, at 23:48, Fabio Maino wrote: >=20 > Luigi,=20 > I agree with all the comments.=20 >=20 > The document attached should reflect all your suggestions.=20 >=20 > A few notes below, just to explicitly ack the changes you suggested.=20= >=20 >=20 > On 10/26/16 2:13 AM, Luigi Iannone wrote: >> Hi Fabio, >>=20 >> Yes we are converging, very few points are left.=20 >>=20 >> Inline are my comments, I snipped everything that we already agreed = up on. >>=20 >> L. >>=20 >>> On 26 Oct 2016, at 02:14, Fabio Maino > wrote: >>>=20 >>=20 >> [snip] >>=20 >>=20 >>>=20 >>>>=20 >>>> Also, what is the MS stubbornly insists in using an algorithm that = the ITR does not support? >>>=20 >>> The MS might not have alternatives, as it might only support one = algorithm.=20 >>>=20 >>=20 >> Sure >>=20 >> The question is: can we have situations in which MS replies always = with the same algorithm (because has no alternatives) and the ITR is = never able to understand that reply (because has no alternatives). >>=20 >> =46rom my understanding this can happen, right?=20 >>=20 >> LISP-SEC has no way to prevent it, right? >>=20 >> What is needed is a policy like =E2=80=9CITR tries using all of the = algorithm it supports and then gives up=E2=80=9D, right? >>=20 >> If the answer to those questions is yes, then IMO this should be = spelled out somewhere. >>=20 >>=20 >=20 > got it. Agreed.=20 >=20 >=20 >>>=20 >>>=20 >> [snip] >>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>> The KDF ID field, specifies the suggested key derivation = function to >>>>>>> be used by the Map-Server to derive the MS-OTK. >>>>>>=20 >>>>>> What happens if the MS will choose a KDF ID not supported by the = ITR? >>>>>> Can you clarify how to solve this situation or explain why this = will never happen? >>>>>=20 >>>>> This is described a few paragraphs below:=20 >>>>> " >>>>> If the KDF ID in the Map-Reply does not match the >>>>> KDF ID requested in the Map-Request, the ITR SHOULD discard the = Map- >>>>> Reply and send, at the first opportunity it needs to, a new = Map- >>>>> Request with a different KDF ID, according to ITR's...=20 >>>>> " >>>>>=20 >>>>=20 >>>> This does not guarantee that the MS will reply with something the = ITR understands=E2=80=A6. >>>=20 >>> For some local ITR's policy it may not be guaranteed. It's a balance = between reachability and security that the ITR will have to choose.=20 >>>=20 >>>=20 >> I am not sure I understand your reply. >>=20 >> My point was the same as above: what if MS and ITR are not able to = talk? >=20 > ok. So this is addressed by the same fix used for the previous = comment. I'll specify that the ITR will stop re-sending map-requests = once all HMAC IDs supported by the ITR have been attempted.=20 > =20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>>=20 >>>>>>> The EID-AD length is set to 4 bytes, since the Authentication = Data >>>>>>> does not contain EID-prefix Authentication Data, and the = EID-AD >>>>>>> contains only the KDF ID field. >>>>>>>=20 >>>>>>> In response to an encapsulated Map-Request that has the S-bit = set, an >>>>>>> ITR MUST receive a Map-Reply with the S-bit set, that = includes an >>>>>>> EID-AD and a PKT-AD. If the Map-Reply does not include both = ADs, the >>>>>>> ITR MUST discard it. In response to an encapsulated = Map-Request with >>>>>>> S-bit set to 0, the ITR expects a Map-Reply with S-bit set to = 0, and >>>>>>> the ITR SHOULD discard the Map-Reply if the S-bit is set. >>>>>> Why a =E2=80=9CSHOULD=E2=80=9D? If the Map-Request has S-bit=3D0 = it mean that there is no AD, hence no OTK, how can the ITR decrypt the = reply????? >>>>>> It MUST discard=E2=80=A6.. >>>>>=20 >>>>> If S-bit =3D 0 there's no Authentication Data. The Map-reply is in = clear, and can be read. >>>>=20 >>>> I am not sure you understood my point. >>>>=20 >>>> You send a Map-Request with S=3D0, hence unenbcrypted. How can you = possible receive a Map-Reply with S=3D1? >>>> How is it encrypted if the ITR did not provide any OTK? >>>=20 >>> Misconfiguration, bugs? I was just trying to enumerate the behaviors = of the ITR. There's probably something wrong, and the map-reply should = be discarded. Still the mapping is readable, so an ITR favoring = reachability may decide to use the mapping.=20 >>>=20 >>=20 >> Oh=E2=80=A6 I may see the misunderstanding. You are saying that the = bit is set in the Map-Reply, but actually the content is not encrypted, = right? SO the ITR can decide whether or not to use it. >>=20 >> Is that right? >=20 > right.=20 >=20 >>=20 >>=20 >> [snip] >>>>>> I think =E2=80=9Clog message" is too much implementation = specific.=20 >>>>>> If there is a notification, and how this notification is done, is = implementation specific IMHO. >>>>> ok. Same as above. >>>>>>=20 >>>>>>> The EID-record with EID-prefix 1.1.2.0/24 is stored in the = map-cache >>>>>>> because it matches the second EID-prefix contained in the = EID-AD. >>>>>>>=20 >>>>>>> The EID-record with EID-prefix 1.2.0.0/16 is not processed = since it >>>>>>> is not included in any of the EID-ADs signed by the = Map-Server. A >>>>>>> log message is issued. >>>>>> I think =E2=80=9Clog message" is too much implementation = specific.=20 >>>>>> If there is a notification, and how this notification is done, is = implementation specific IMHO. >>>>> ok. Same as above >>>>>>=20 >>>>>>> In this last example the ETR is trying to >>>>>>> over claim the EID-prefix 1.2.0.0/16, but the Map-Server = authorized >>>>>>> only 1.2.3.0/24, hence the EID-record is discarded. >>>>>> Reading the example I am not sure I would follow this behaviour. >>>>>> Only 1 record out of 3 is valid so why should I actually trust = the ETR instead of throwing everything away? >>>>>> Can you explain ??? >>>>> The other two records are validated by the MS, so there is no = reason to throw those away. >>>>=20 >>>> Yes, but the ETR is still trying to cheat on the third one=E2=80=A6. >>>> So the ETR may be compromised, why should I send traffic to him??? >>>=20 >>> ITR has flagged the security exception with the log entry, and some = local ITR policy will decide what to do (including stop encapsulating to = the ETR, if that's what is specified by the policy). At the LISP level = LISP-SEC has done its job: verified mapping goes into the map-cache, = overclaimed mapping is dropped.=20 >>>=20 >>=20 >> This is not what the above text states. The text states that the = valid EID-record is stored in the map-cache. >> To be consistent with your reply you should change and state that the = EID-record is eligible to be used by the ITR. >=20 >=20 > got it. I changed 'stored into the map-cache' with 'eligible to be = used by the ITR'. For consistency I have used similar language for the = other two cases (rather than not processed). =20 >=20 >>=20 >> BTW to be consistent with other LISP document you should use "LISP = Cache=E2=80=9D instead of =E2=80=9Cmap-cache=E2=80=9D (in the whole = document). >>=20 >>=20 > ok. With the change above we don't use the word map-cache anymore in = the document. So this is addresses as well. >=20 > Thanks! > Fabio >=20 >=20 >=20 >> [snip] >>=20 >=20 > --Apple-Mail=_679F300A-EE9E-4682-B138-1CFC6DC543A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Fabio,

I= went through the last version of the document.

I still think that in a few place = SHOULD should be replaced by MUST. But it is just  my point of = view. You can leave SHOULD.

There are just few residual issues:

- Introduction: The second sentence is = not coherent with the first one. The concept of EID-to-RLOC mappings as = not been introduced so starting the sentence with =E2=80=9CThese = EID-to-RLOC mapping s=E2=80=A6=E2=80=9D is pretty unclear. I would = suggest you add another sentence.

- Section 7 IANA Considerations: For = almost all of the registries the value =E2=80=9C0=E2=80=9D has a special = meaning that this demo is defining, hence the =E2=80=9Cdefined in=E2=80=9D= field should state =E2=80=9Cthis memo=E2=80=9D

- - Section 7 IANA Considerations: The = section is not yet 5226 compliant. More specifically, you have to state = for each registry how new values are allocated (e.g. FCFS, expert = review, etc..)


Check again the = nits:

 =
Checking nits according to http://www.ietf.org/id-info/checklist :
  =
--------------------------------------------------------------------------=
--

  =3D=3D There are 10 instances of lines with non-RFC6890-compliant IPv4
     addresses in the document.  If these are example addresses, they =
should
     be changed.

  Checking references for intended status: Experimental
  =
--------------------------------------------------------------------------=
--

  =3D=3D Missing Reference: 'RFC4634' is mentioned on line 840, but not =
defined

  ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)


The above nits reminds me of another = issue that the IESG will certainly raise: can we have all the examples = in IPv6 only?
The latest directives are that either = you use both v4 and v6 or v6-only, but NOT v4-only.

Thanks

ciao

L.




On = 27 Oct 2016, at 23:48, Fabio Maino <fmaino@cisco.com> wrote:

=20 =20
Luigi,
I agree with all the comments.

The document attached should reflect all your suggestions.

A few notes below, just to explicitly ack the changes you suggested.


On 10/26/16 2:13 AM, Luigi Iannone wrote:
Hi Fabio,

Yes we are converging, very few points are = left. 

Inline are my comments, I snipped everything that = we already agreed up on.

L.

On 26 Oct 2016, at 02:14, Fabio Maino <fmaino@cisco.com> wrote:


[snip]




Also, what is the MS stubbornly insists in using an algorithm that the ITR does not support?

The MS might not have alternatives, as it might only support one algorithm.


Sure

The question is: can we have situations in = which MS replies always with the same algorithm (because has no alternatives) and the ITR is never able to understand that reply (because has no alternatives).

=46rom my understanding this can happen, = right? 

LISP-SEC has no way to prevent it, = right?

What is needed is a policy like =E2=80=9CITR = tries using all of the algorithm it supports and then gives up=E2=80=9D, = right?

If the answer to those questions is yes, then = IMO this should be spelled out somewhere.



got it. Agreed.




[snip]




   The KDF ID field, specifies the =
suggested key derivation function to
   be used by the Map-Server to derive the MS-OTK.

What happens if the MS will choose a KDF ID not supported by the ITR?
Can you clarify how to solve this situation or explain why this will never happen?

This is described a few paragraphs below: =
" 
If the KDF ID in the =
Map-Reply does not match the
   KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
   Reply and send, at the first opportunity it needs to, a new Map-
   Request with a different KDF ID, according to ITR's...
"


This does not guarantee that the = MS will reply with something the ITR = understands=E2=80=A6.

For some local ITR's policy it may not be guaranteed. It's a balance between reachability and security that the ITR will have to choose.


I am not sure I understand your reply.

My point was the same as above: what if MS and = ITR are not able to talk?

ok. So this is addressed by the same fix used for the previous comment. I'll specify that the ITR will stop re-sending map-requests once all HMAC IDs supported by the ITR have been attempted.
 










   The EID-AD length is set to 4 =
bytes, since the Authentication Data
   does not contain EID-prefix Authentication Data, and the EID-AD
   contains only the KDF ID field.

   In response to an encapsulated Map-Request that has the S-bit set, an
   ITR MUST receive a Map-Reply with the S-bit set, that includes an
   EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
   ITR MUST discard it.  In response to an encapsulated Map-Request with
   S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
   the ITR SHOULD discard the Map-Reply if the S-bit is set.
Why a =E2=80=9CSHOULD=E2=80= =9D? If the Map-Request has S-bit=3D0 it mean that there is no AD, hence no OTK, how can the ITR decrypt the reply?????
It MUST = discard=E2=80=A6..

If S-bit =3D 0 there's no Authentication = Data. The Map-reply is in clear, and can be = read.

I am not sure you understood my point.

You send a Map-Request with S=3D0, hence unenbcrypted. How can you possible receive a Map-Reply with S=3D1?
How is it encrypted if the ITR did not provide any OTK?

Misconfiguration, bugs? I was just trying to enumerate the behaviors of the ITR. There's probably something wrong, and the map-reply should be discarded. Still the mapping is readable, so an ITR favoring reachability may decide to use the mapping.


Oh=E2=80=A6 I may see the misunderstanding. = You are saying that the bit is set in the Map-Reply, but actually the content is not encrypted, right? SO the ITR can decide whether or not to use it.

Is that right?

right.



[snip]
I think =E2=80=9Clog = message" is too much implementation = specific. 
If there is a notification, and how this notification is done, is implementation specific IMHO.
ok. Same as above. 
   The EID-record with EID-prefix =
1.1.2.0/24 is stored in the map-cache
   because it matches the second EID-prefix contained in the EID-AD.

   The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
   is not included in any of the EID-ADs signed by the Map-Server.  A
   log message is issued.
I think =E2=80=9Clog = message" is too much implementation = specific. 
If there is a notification, and how this notification is done, is implementation specific IMHO.
ok. Same as above 
  In this last example the ETR is =
trying to
   over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
   only 1.2.3.0/24, hence the EID-record is discarded.
Reading the example I am not sure I would follow this behaviour.
Only 1 record out of 3 = is valid so why should I actually trust the ETR instead of throwing everything away?
Can you explain = ???
The other two records are validated by the MS, so there is no reason to throw those away.

Yes, but the ETR is still trying = to cheat on the third one=E2=80=A6.
So the ETR may be compromised, why should I send traffic to him???

ITR has flagged the security exception with the log entry, and some local ITR policy will decide what to do (including stop encapsulating to the ETR, if that's what is specified by the policy).  At the LISP level = LISP-SEC has done its job: verified mapping  goes into the map-cache, overclaimed mapping is dropped.
=

This is not what the above text states. The = text states that the valid EID-record is stored in the map-cache.
To be consistent with your reply you should = change and state that the EID-record is eligible to be used by the = ITR.


got it. I changed 'stored into the map-cache' with 'eligible to be used by the ITR'. For consistency I have used similar language for the other two cases (rather than not processed). 
=

BTW to be consistent with other LISP document = you should use "LISP Cache=E2=80=9D instead of =E2=80=9Cmap-cache=E2=80=9D= (in the whole document).


ok. With the change above we don't use the word map-cache anymore in the document. So this is addresses as well.

Thanks!
Fabio



[snip]


<Diff_ = draft-ietf-lisp-sec-11.txt - = draft-ietf-lisp-sec-12b.txt.html><draft-ietf-lis= p-sec-12b.txt>

= --Apple-Mail=_679F300A-EE9E-4682-B138-1CFC6DC543A1-- From nobody Wed Nov 2 16:24:39 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A3129677; Wed, 2 Nov 2016 16:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGevleliE2Nv; Wed, 2 Nov 2016 16:24:34 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9671296FD; Wed, 2 Nov 2016 16:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42970; q=dns/txt; s=iport; t=1478129072; x=1479338672; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=UnHOFI1Zw0ohMb7duDXeqKnzKOP+0E/g2gChAHrAh5k=; b=UyuHS0VFhzrXEtIe1B9JohBrzDnKwNL2FJRv0MrtOQ6EsE2VNo+ImaJT VPW3W3+Hyl+NFj687oV4oHhzOel507MyLmcCXmPYLg8AddI3GSxSYy0Xt L3VeWlYDQGRZz77Poon95tSHybDtki+xL+yDGLR820qQJ9DB25pbGlLpX Q=; X-IronPort-AV: E=Sophos;i="5.31,436,1473120000"; d="scan'208,217";a="341654751" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2016 23:24:32 +0000 Received: from [10.154.249.82] ([10.154.249.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id uA2NOVV7007343; Wed, 2 Nov 2016 23:24:31 GMT To: Luigi Iannone References: <8204baa6-8cbd-83b3-aa88-dc3ba16c5a33@cisco.com> <38FE74C1-A8F3-4A92-B575-CC5CF4E249D8@telecom-paristech.fr> <37a920e9-b1aa-33c1-6321-e24937bc6c8d@cisco.com> <204F0A89-BEB8-4BDF-A363-4AABDBF4E262@telecom-paristech.fr> From: Fabio Maino Message-ID: <228ae951-d5d4-d3fc-fbc0-418b09ec3b4e@cisco.com> Date: Wed, 2 Nov 2016 16:24:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <204F0A89-BEB8-4BDF-A363-4AABDBF4E262@telecom-paristech.fr> Content-Type: multipart/alternative; boundary="------------058F528830D457CDB901D28D" Archived-At: Cc: lisp-chairs@ietf.org, Damien Saucez , LISP mailing list list Subject: Re: [lisp] LISP-SEC review (finally) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 23:24:37 -0000 This is a multi-part message in MIME format. --------------058F528830D457CDB901D28D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/2/16 9:02 AM, Luigi Iannone wrote: > Hi Fabio, > > I went through the last version of the document. > > I still think that in a few place SHOULD should be replaced by MUST. > But it is just my point of view. You can leave SHOULD. > > There are just few residual issues: > > - Introduction: The second sentence is not coherent with the first > one. The concept of EID-to-RLOC mappings as not been introduced so > starting the sentence with “These EID-to-RLOC mapping s…” is pretty > unclear. I would suggest you add another sentence. > > - Section 7 IANA Considerations: For almost all of the registries the > value “0” has a special meaning that this demo is defining, hence the > “defined in” field should state “this memo” > > - - Section 7 IANA Considerations: The section is not yet 5226 > compliant. More specifically, you have to state for each registry how > new values are allocated (e.g. FCFS, expert review, etc..) Thanks Luigi, do you have any suggestion for the best policy to use for allocation of unassigned values? It seems to me that given the experimental nature of the draft, for all of the registries created, we could require that 'unassigned values are to be assigned according to the "Specification Required" policy defined in [RFC5226].' Fabio > > > Check again the nits: > > Checking nits according tohttp://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > == There are 10 instances of lines with non-RFC6890-compliant IPv4 > addresses in the document. If these are example addresses, they should > be changed. > > Checking references for intended status: Experimental > ---------------------------------------------------------------------------- > > == Missing Reference: 'RFC4634' is mentioned on line 840, but not defined > > ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234) > > > The above nits reminds me of another issue that the IESG will > certainly raise: can we have all the examples in IPv6 only? > The latest directives are that either you use both v4 and v6 or > v6-only, but NOT v4-only. > > Thanks > > ciao > > L. > > > > >> On 27 Oct 2016, at 23:48, Fabio Maino > > wrote: >> >> Luigi, >> I agree with all the comments. >> >> The document attached should reflect all your suggestions. >> >> A few notes below, just to explicitly ack the changes you suggested. >> >> >> On 10/26/16 2:13 AM, Luigi Iannone wrote: >>> Hi Fabio, >>> >>> Yes we are converging, very few points are left. >>> >>> Inline are my comments, I snipped everything that we already agreed >>> up on. >>> >>> L. >>> >>>> On 26 Oct 2016, at 02:14, Fabio Maino >>> > wrote: >>>> >>> >>> [snip] >>> >>> >>>> >>>>> >>>>> Also, what is the MS stubbornly insists in using an algorithm that >>>>> the ITR does not support? >>>> >>>> The MS might not have alternatives, as it might only support one >>>> algorithm. >>>> >>> >>> Sure >>> >>> The question is: can we have situations in which MS replies always >>> with the same algorithm (because has no alternatives) and the ITR is >>> never able to understand that reply (because has no alternatives). >>> >>> From my understanding this can happen, right? >>> >>> LISP-SEC has no way to prevent it, right? >>> >>> What is needed is a policy like “ITR tries using all of the >>> algorithm it supports and then gives up”, right? >>> >>> If the answer to those questions is yes, then IMO this should be >>> spelled out somewhere. >>> >>> >> >> got it. Agreed. >> >> >>>> >>>> >>> [snip] >>> >>>>> >>>>>> >>>>>>> >>>>>>>> The KDF ID field, specifies the suggested key derivation function to >>>>>>>> be used by the Map-Server to derive the MS-OTK. >>>>>>> >>>>>>> What happens if the MS will choose a KDF ID not supported by the >>>>>>> ITR? >>>>>>> Can you clarify how to solve this situation or explain why this >>>>>>> will never happen? >>>>>> >>>>>> This is described a few paragraphs below: >>>>>> " >>>>>> If the KDF ID in the Map-Reply does not match the >>>>>> KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- >>>>>> Reply and send, at the first opportunity it needs to, a new Map- >>>>>> Request with a different KDF ID, according to ITR's... >>>>>> " >>>>>> >>>>> >>>>> This does not guarantee that the MS will reply with something the >>>>> ITR understands…. >>>> >>>> For some local ITR's policy it may not be guaranteed. It's a >>>> balance between reachability and security that the ITR will have to >>>> choose. >>>> >>>> >>> I am not sure I understand your reply. >>> >>> My point was the same as above: what if MS and ITR are not able to talk? >> >> ok. So this is addressed by the same fix used for the previous >> comment. I'll specify that the ITR will stop re-sending map-requests >> once all HMAC IDs supported by the ITR have been attempted. >> >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>>>> >>>>>>>> The EID-AD length is set to 4 bytes, since the Authentication Data >>>>>>>> does not contain EID-prefix Authentication Data, and the EID-AD >>>>>>>> contains only the KDF ID field. >>>>>>>> >>>>>>>> In response to an encapsulated Map-Request that has the S-bit set, an >>>>>>>> ITR MUST receive a Map-Reply with the S-bit set, that includes an >>>>>>>> EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the >>>>>>>> ITR MUST discard it. In response to an encapsulated Map-Request with >>>>>>>> S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and >>>>>>>> the ITR SHOULD discard the Map-Reply if the S-bit is set. >>>>>>> Why a “SHOULD”? If the Map-Request has S-bit=0 it mean that >>>>>>> there is no AD, hence no OTK, how can the ITR decrypt the reply????? >>>>>>> It MUST discard….. >>>>>> >>>>>> If S-bit = 0 there's no Authentication Data. The Map-reply is in >>>>>> clear, and can be read. >>>>> >>>>> I am not sure you understood my point. >>>>> >>>>> You send a Map-Request with S=0, hence unenbcrypted. How can you >>>>> possible receive a Map-Reply with S=1? >>>>> How is it encrypted if the ITR did not provide any OTK? >>>> >>>> Misconfiguration, bugs? I was just trying to enumerate the >>>> behaviors of the ITR. There's probably something wrong, and the >>>> map-reply should be discarded. Still the mapping is readable, so an >>>> ITR favoring reachability may decide to use the mapping. >>>> >>> >>> Oh… I may see the misunderstanding. You are saying that the bit is >>> set in the Map-Reply, but actually the content is not encrypted, >>> right? SO the ITR can decide whether or not to use it. >>> >>> Is that right? >> >> right. >> >>> >>> >>> [snip] >>>>>>> I think “log message" is too much implementation specific. >>>>>>> If there is a notification, and how this notification is done, >>>>>>> is implementation specific IMHO. >>>>>> ok. Same as above. >>>>>>>> The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache >>>>>>>> because it matches the second EID-prefix contained in the EID-AD. >>>>>>>> >>>>>>>> The EID-record with EID-prefix 1.2.0.0/16 is not processed since it >>>>>>>> is not included in any of the EID-ADs signed by the Map-Server. A >>>>>>>> log message is issued. >>>>>>> I think “log message" is too much implementation specific. >>>>>>> If there is a notification, and how this notification is done, >>>>>>> is implementation specific IMHO. >>>>>> ok. Same as above >>>>>>>> In this last example the ETR is trying to >>>>>>>> over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized >>>>>>>> only 1.2.3.0/24, hence the EID-record is discarded. >>>>>>> Reading the example I am not sure I would follow this behaviour. >>>>>>> Only 1 record out of 3 is valid so why should I actually trust >>>>>>> the ETR instead of throwing everything away? >>>>>>> Can you explain ??? >>>>>> The other two records are validated by the MS, so there is no >>>>>> reason to throw those away. >>>>> >>>>> Yes, but the ETR is still trying to cheat on the third one…. >>>>> So the ETR may be compromised, why should I send traffic to him??? >>>> >>>> ITR has flagged the security exception with the log entry, and some >>>> local ITR policy will decide what to do (including stop >>>> encapsulating to the ETR, if that's what is specified by the >>>> policy). At the LISP level LISP-SEC has done its job: verified >>>> mapping goes into the map-cache, overclaimed mapping is dropped. >>>> >>> >>> This is not what the above text states. The text states that the >>> valid EID-record is stored in the map-cache. >>> To be consistent with your reply you should change and state that >>> the EID-record is eligible to be used by the ITR. >> >> >> got it. I changed 'stored into the map-cache' with 'eligible to be >> used by the ITR'. For consistency I have used similar language for >> the other two cases (rather than not processed). >> >>> >>> BTW to be consistent with other LISP document you should use "LISP >>> Cache” instead of “map-cache” (in the whole document). >>> >>> >> ok. With the change above we don't use the word map-cache anymore in >> the document. So this is addresses as well. >> >> Thanks! >> Fabio >> >> >> >>> [snip] >>> >> >> > draft-ietf-lisp-sec-12b.txt.html> > --------------058F528830D457CDB901D28D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/2/16 9:02 AM, Luigi Iannone wrote:
Hi Fabio,

I went through the last version of the document.

I still think that in a few place SHOULD should be replaced by MUST. But it is just  my point of view. You can leave SHOULD.

There are just few residual issues:

- Introduction: The second sentence is not coherent with the first one. The concept of EID-to-RLOC mappings as not been introduced so starting the sentence with “These EID-to-RLOC mapping s…” is pretty unclear. I would suggest you add another sentence.

- Section 7 IANA Considerations: For almost all of the registries the value “0” has a special meaning that this demo is defining, hence the “defined in” field should state “this memo”

- - Section 7 IANA Considerations: The section is not yet 5226 compliant. More specifically, you have to state for each registry how new values are allocated (e.g. FCFS, expert review, etc..)

Thanks Luigi,
do you have any suggestion for the best policy to use for allocation of unassigned values?

It seems to me that given the experimental nature of the draft, for all of the registries created, we could require that 'unassigned values are to be assigned according to the "Specification Required" policy defined in [RFC5226].'

  

Fabio





Check again the nits:

 Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 10 instances of lines with non-RFC6890-compliant IPv4
     addresses in the document.  If these are example addresses, they should
     be changed.

  Checking references for intended status: Experimental
  ----------------------------------------------------------------------------

  == Missing Reference: 'RFC4634' is mentioned on line 840, but not defined

  ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)


The above nits reminds me of another issue that the IESG will certainly raise: can we have all the examples in IPv6 only?
The latest directives are that either you use both v4 and v6 or v6-only, but NOT v4-only.

Thanks

ciao

L.




On 27 Oct 2016, at 23:48, Fabio Maino <fmaino@cisco.com> wrote:

Luigi,
I agree with all the comments.

The document attached should reflect all your suggestions.

A few notes below, just to explicitly ack the changes you suggested.


On 10/26/16 2:13 AM, Luigi Iannone wrote:
Hi Fabio,

Yes we are converging, very few points are left. 

Inline are my comments, I snipped everything that we already agreed up on.

L.

On 26 Oct 2016, at 02:14, Fabio Maino <fmaino@cisco.com> wrote:


[snip]




Also, what is the MS stubbornly insists in using an algorithm that the ITR does not support?

The MS might not have alternatives, as it might only support one algorithm.


Sure

The question is: can we have situations in which MS replies always with the same algorithm (because has no alternatives) and the ITR is never able to understand that reply (because has no alternatives).

From my understanding this can happen, right? 

LISP-SEC has no way to prevent it, right?

What is needed is a policy like “ITR tries using all of the algorithm it supports and then gives up”, right?

If the answer to those questions is yes, then IMO this should be spelled out somewhere.



got it. Agreed.




[snip]




   The KDF ID field, specifies the suggested key derivation function to
   be used by the Map-Server to derive the MS-OTK.

What happens if the MS will choose a KDF ID not supported by the ITR?
Can you clarify how to solve this situation or explain why this will never happen?

This is described a few paragraphs below:
" 
If the KDF ID in the Map-Reply does not match the
   KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
   Reply and send, at the first opportunity it needs to, a new Map-
   Request with a different KDF ID, according to ITR's...
"


This does not guarantee that the MS will reply with something the ITR understands….

For some local ITR's policy it may not be guaranteed. It's a balance between reachability and security that the ITR will have to choose.


I am not sure I understand your reply.

My point was the same as above: what if MS and ITR are not able to talk?

ok. So this is addressed by the same fix used for the previous comment. I'll specify that the ITR will stop re-sending map-requests once all HMAC IDs supported by the ITR have been attempted.
 










   The EID-AD length is set to 4 bytes, since the Authentication Data
   does not contain EID-prefix Authentication Data, and the EID-AD
   contains only the KDF ID field.

   In response to an encapsulated Map-Request that has the S-bit set, an
   ITR MUST receive a Map-Reply with the S-bit set, that includes an
   EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
   ITR MUST discard it.  In response to an encapsulated Map-Request with
   S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
   the ITR SHOULD discard the Map-Reply if the S-bit is set.
Why a “SHOULD”? If the Map-Request has S-bit=0 it mean that there is no AD, hence no OTK, how can the ITR decrypt the reply?????
It MUST discard…..

If S-bit = 0 there's no Authentication Data. The Map-reply is in clear, and can be read.

I am not sure you understood my point.

You send a Map-Request with S=0, hence unenbcrypted. How can you possible receive a Map-Reply with S=1?
How is it encrypted if the ITR did not provide any OTK?

Misconfiguration, bugs? I was just trying to enumerate the behaviors of the ITR. There's probably something wrong, and the map-reply should be discarded. Still the mapping is readable, so an ITR favoring reachability may decide to use the mapping.


Oh… I may see the misunderstanding. You are saying that the bit is set in the Map-Reply, but actually the content is not encrypted, right? SO the ITR can decide whether or not to use it.

Is that right?

right.



[snip]
I think “log message" is too much implementation specific. 
If there is a notification, and how this notification is done, is implementation specific IMHO.
ok. Same as above. 
   The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache
   because it matches the second EID-prefix contained in the EID-AD.

   The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
   is not included in any of the EID-ADs signed by the Map-Server.  A
   log message is issued.
I think “log message" is too much implementation specific. 
If there is a notification, and how this notification is done, is implementation specific IMHO.
ok. Same as above 
  In this last example the ETR is trying to
   over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
   only 1.2.3.0/24, hence the EID-record is discarded.
Reading the example I am not sure I would follow this behaviour.
Only 1 record out of 3 is valid so why should I actually trust the ETR instead of throwing everything away?
Can you explain ???
The other two records are validated by the MS, so there is no reason to throw those away.

Yes, but the ETR is still trying to cheat on the third one….
So the ETR may be compromised, why should I send traffic to him???

ITR has flagged the security exception with the log entry, and some local ITR policy will decide what to do (including stop encapsulating to the ETR, if that's what is specified by the policy).  At the LISP level LISP-SEC has done its job: verified mapping  goes into the map-cache, overclaimed mapping is dropped.


This is not what the above text states. The text states that the valid EID-record is stored in the map-cache.
To be consistent with your reply you should change and state that the EID-record is eligible to be used by the ITR.


got it. I changed 'stored into the map-cache' with 'eligible to be used by the ITR'. For consistency I have used similar language for the other two cases (rather than not processed). 


BTW to be consistent with other LISP document you should use "LISP Cache” instead of “map-cache” (in the whole document).


ok. With the change above we don't use the word map-cache anymore in the document. So this is addresses as well.

Thanks!
Fabio



[snip]


<Diff_ draft-ietf-lisp-sec-11.txt - draft-ietf-lisp-sec-12b.txt.html><draft-ietf-lisp-sec-12b.txt>


--------------058F528830D457CDB901D28D-- From nobody Thu Nov 3 01:01:41 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0421294E3; Thu, 3 Nov 2016 01:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-paristech.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBZ3xEOuQeBg; Thu, 3 Nov 2016 01:01:34 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) by ietfa.amsl.com (Postfix) with ESMTP id 06E81129473; Thu, 3 Nov 2016 01:01:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 2D7BC100788; Thu, 3 Nov 2016 09:01:33 +0100 (CET) Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GuRm26sOXb7T; Thu, 3 Nov 2016 09:01:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 74ABE10073F; Thu, 3 Nov 2016 09:01:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy110.enst.fr 74ABE10073F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1478160091; bh=JHxKxKoCSpiH/6vySbtTjKlOiR2s8ugXykI1Q/316b4=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=iQr+dFotK8fCVJ+BfVOVhjbecB1VuutMZOsSYha7EhUvvt8+nsEIWDiJfCGgpePXb 22CIzPATD9pjEQwM8FzgFW3XRgAGeUlkUPUrE+VcC+s7OhLQuwbT+D9neVIYBctgt7 ICZvc+RJ/MB465FdCWmuoj/RRjbePNmXvJffpsMg= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rPljlf1VLxEN; Thu, 3 Nov 2016 09:01:31 +0100 (CET) Received: from dhcp164-48.enst.fr (dhcp164-48.enst.fr [137.194.165.48]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 34EB2FF6A8; Thu, 3 Nov 2016 09:01:31 +0100 (CET) From: Luigi Iannone Message-Id: <2DC9866F-49C3-411F-AE3D-6331299C9FC1@telecom-paristech.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_25CE40F6-3506-4EAA-8CDF-F92BF096485D" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 3 Nov 2016 09:01:36 +0100 In-Reply-To: <228ae951-d5d4-d3fc-fbc0-418b09ec3b4e@cisco.com> To: Fabio Maino References: <8204baa6-8cbd-83b3-aa88-dc3ba16c5a33@cisco.com> <38FE74C1-A8F3-4A92-B575-CC5CF4E249D8@telecom-paristech.fr> <37a920e9-b1aa-33c1-6321-e24937bc6c8d@cisco.com> <204F0A89-BEB8-4BDF-A363-4AABDBF4E262@telecom-paristech.fr> <228ae951-d5d4-d3fc-fbc0-418b09ec3b4e@cisco.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, Damien Saucez , LISP mailing list list Subject: Re: [lisp] LISP-SEC review (finally) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 08:01:40 -0000 --Apple-Mail=_25CE40F6-3506-4EAA-8CDF-F92BF096485D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3 Nov 2016, at 00:24, Fabio Maino wrote: >=20 > On 11/2/16 9:02 AM, Luigi Iannone wrote: >> Hi Fabio, >>=20 >> I went through the last version of the document. >>=20 >> I still think that in a few place SHOULD should be replaced by MUST. = But it is just my point of view. You can leave SHOULD. >>=20 >> There are just few residual issues: >>=20 >> - Introduction: The second sentence is not coherent with the first = one. The concept of EID-to-RLOC mappings as not been introduced so = starting the sentence with =E2=80=9CThese EID-to-RLOC mapping s=E2=80=A6=E2= =80=9D is pretty unclear. I would suggest you add another sentence. >>=20 >> - Section 7 IANA Considerations: For almost all of the registries the = value =E2=80=9C0=E2=80=9D has a special meaning that this demo is = defining, hence the =E2=80=9Cdefined in=E2=80=9D field should state = =E2=80=9Cthis memo=E2=80=9D >>=20 >> - - Section 7 IANA Considerations: The section is not yet 5226 = compliant. More specifically, you have to state for each registry how = new values are allocated (e.g. FCFS, expert review, etc..) >=20 > Thanks Luigi,=20 > do you have any suggestion for the best policy to use for allocation = of unassigned values?=20 >=20 > It seems to me that given the experimental nature of the draft, for = all of the registries created, we could require that 'unassigned values = are to be assigned according to the "Specification Required" policy = defined in [RFC5226].' >=20 Hi, I have no strong opinion on the issue. To be honest, since the size of = the fields are pretty big considered their potential use I would simply = go for a FCFS. Even if some values are wasted there is a large space.=20 If instead you want to be sure to always have something meaningful, = without introducing heavy machinery, I would go for =E2=80=9CExpert = Review=E2=80=9D. Ciao L. > =20 >=20 > Fabio >=20 >=20 >=20 >>=20 >>=20 >> Check again the nits: >>=20 >> Checking nits according to http://www.ietf.org/id-info/checklist = : >> = --------------------------------------------------------------------------= -- >>=20 >> =3D=3D There are 10 instances of lines with non-RFC6890-compliant = IPv4 >> addresses in the document. If these are example addresses, they = should >> be changed. >>=20 >> Checking references for intended status: Experimental >> = --------------------------------------------------------------------------= -- >>=20 >> =3D=3D Missing Reference: 'RFC4634' is mentioned on line 840, but = not defined >>=20 >> ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234) >>=20 >>=20 >> The above nits reminds me of another issue that the IESG will = certainly raise: can we have all the examples in IPv6 only? >> The latest directives are that either you use both v4 and v6 or = v6-only, but NOT v4-only. >>=20 >> Thanks >>=20 >> ciao >>=20 >> L. >>=20 >>=20 >>=20 >>=20 >>> On 27 Oct 2016, at 23:48, Fabio Maino > wrote: >>>=20 >>> Luigi,=20 >>> I agree with all the comments.=20 >>>=20 >>> The document attached should reflect all your suggestions.=20 >>>=20 >>> A few notes below, just to explicitly ack the changes you suggested.=20= >>>=20 >>>=20 >>> On 10/26/16 2:13 AM, Luigi Iannone wrote: >>>> Hi Fabio, >>>>=20 >>>> Yes we are converging, very few points are left.=20 >>>>=20 >>>> Inline are my comments, I snipped everything that we already agreed = up on. >>>>=20 >>>> L. >>>>=20 >>>>> On 26 Oct 2016, at 02:14, Fabio Maino > wrote: >>>>>=20 >>>>=20 >>>> [snip] >>>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Also, what is the MS stubbornly insists in using an algorithm = that the ITR does not support? >>>>>=20 >>>>> The MS might not have alternatives, as it might only support one = algorithm.=20 >>>>>=20 >>>>=20 >>>> Sure >>>>=20 >>>> The question is: can we have situations in which MS replies always = with the same algorithm (because has no alternatives) and the ITR is = never able to understand that reply (because has no alternatives). >>>>=20 >>>> =46rom my understanding this can happen, right?=20 >>>>=20 >>>> LISP-SEC has no way to prevent it, right? >>>>=20 >>>> What is needed is a policy like =E2=80=9CITR tries using all of the = algorithm it supports and then gives up=E2=80=9D, right? >>>>=20 >>>> If the answer to those questions is yes, then IMO this should be = spelled out somewhere. >>>>=20 >>>>=20 >>>=20 >>> got it. Agreed.=20 >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>> [snip] >>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> The KDF ID field, specifies the suggested key derivation = function to >>>>>>>>> be used by the Map-Server to derive the MS-OTK. >>>>>>>>=20 >>>>>>>> What happens if the MS will choose a KDF ID not supported by = the ITR? >>>>>>>> Can you clarify how to solve this situation or explain why this = will never happen? >>>>>>>=20 >>>>>>> This is described a few paragraphs below:=20 >>>>>>> " >>>>>>> If the KDF ID in the Map-Reply does not match the >>>>>>> KDF ID requested in the Map-Request, the ITR SHOULD discard = the Map- >>>>>>> Reply and send, at the first opportunity it needs to, a new = Map- >>>>>>> Request with a different KDF ID, according to ITR's...=20 >>>>>>> " >>>>>>>=20 >>>>>>=20 >>>>>> This does not guarantee that the MS will reply with something the = ITR understands=E2=80=A6. >>>>>=20 >>>>> For some local ITR's policy it may not be guaranteed. It's a = balance between reachability and security that the ITR will have to = choose.=20 >>>>>=20 >>>>>=20 >>>> I am not sure I understand your reply. >>>>=20 >>>> My point was the same as above: what if MS and ITR are not able to = talk? >>>=20 >>> ok. So this is addressed by the same fix used for the previous = comment. I'll specify that the ITR will stop re-sending map-requests = once all HMAC IDs supported by the ITR have been attempted.=20 >>> =20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>>=20 >>>>>>>>> The EID-AD length is set to 4 bytes, since the = Authentication Data >>>>>>>>> does not contain EID-prefix Authentication Data, and the = EID-AD >>>>>>>>> contains only the KDF ID field. >>>>>>>>>=20 >>>>>>>>> In response to an encapsulated Map-Request that has the = S-bit set, an >>>>>>>>> ITR MUST receive a Map-Reply with the S-bit set, that = includes an >>>>>>>>> EID-AD and a PKT-AD. If the Map-Reply does not include = both ADs, the >>>>>>>>> ITR MUST discard it. In response to an encapsulated = Map-Request with >>>>>>>>> S-bit set to 0, the ITR expects a Map-Reply with S-bit set = to 0, and >>>>>>>>> the ITR SHOULD discard the Map-Reply if the S-bit is set. >>>>>>>> Why a =E2=80=9CSHOULD=E2=80=9D? If the Map-Request has S-bit=3D0 = it mean that there is no AD, hence no OTK, how can the ITR decrypt the = reply????? >>>>>>>> It MUST discard=E2=80=A6.. >>>>>>>=20 >>>>>>> If S-bit =3D 0 there's no Authentication Data. The Map-reply is = in clear, and can be read. >>>>>>=20 >>>>>> I am not sure you understood my point. >>>>>>=20 >>>>>> You send a Map-Request with S=3D0, hence unenbcrypted. How can = you possible receive a Map-Reply with S=3D1? >>>>>> How is it encrypted if the ITR did not provide any OTK? >>>>>=20 >>>>> Misconfiguration, bugs? I was just trying to enumerate the = behaviors of the ITR. There's probably something wrong, and the = map-reply should be discarded. Still the mapping is readable, so an ITR = favoring reachability may decide to use the mapping.=20 >>>>>=20 >>>>=20 >>>> Oh=E2=80=A6 I may see the misunderstanding. You are saying that the = bit is set in the Map-Reply, but actually the content is not encrypted, = right? SO the ITR can decide whether or not to use it. >>>>=20 >>>> Is that right? >>>=20 >>> right.=20 >>>=20 >>>>=20 >>>>=20 >>>> [snip] >>>>>>>> I think =E2=80=9Clog message" is too much implementation = specific.=20 >>>>>>>> If there is a notification, and how this notification is done, = is implementation specific IMHO. >>>>>>> ok. Same as above. >>>>>>>>=20 >>>>>>>>> The EID-record with EID-prefix 1.1.2.0/24 is stored in the = map-cache >>>>>>>>> because it matches the second EID-prefix contained in the = EID-AD. >>>>>>>>>=20 >>>>>>>>> The EID-record with EID-prefix 1.2.0.0/16 is not processed = since it >>>>>>>>> is not included in any of the EID-ADs signed by the = Map-Server. A >>>>>>>>> log message is issued. >>>>>>>> I think =E2=80=9Clog message" is too much implementation = specific.=20 >>>>>>>> If there is a notification, and how this notification is done, = is implementation specific IMHO. >>>>>>> ok. Same as above >>>>>>>>=20 >>>>>>>>> In this last example the ETR is trying to >>>>>>>>> over claim the EID-prefix 1.2.0.0/16, but the Map-Server = authorized >>>>>>>>> only 1.2.3.0/24, hence the EID-record is discarded. >>>>>>>> Reading the example I am not sure I would follow this = behaviour. >>>>>>>> Only 1 record out of 3 is valid so why should I actually trust = the ETR instead of throwing everything away? >>>>>>>> Can you explain ??? >>>>>>> The other two records are validated by the MS, so there is no = reason to throw those away. >>>>>>=20 >>>>>> Yes, but the ETR is still trying to cheat on the third one=E2=80=A6= . >>>>>> So the ETR may be compromised, why should I send traffic to = him??? >>>>>=20 >>>>> ITR has flagged the security exception with the log entry, and = some local ITR policy will decide what to do (including stop = encapsulating to the ETR, if that's what is specified by the policy). = At the LISP level LISP-SEC has done its job: verified mapping goes into = the map-cache, overclaimed mapping is dropped.=20 >>>>>=20 >>>>=20 >>>> This is not what the above text states. The text states that the = valid EID-record is stored in the map-cache. >>>> To be consistent with your reply you should change and state that = the EID-record is eligible to be used by the ITR. >>>=20 >>>=20 >>> got it. I changed 'stored into the map-cache' with 'eligible to be = used by the ITR'. For consistency I have used similar language for the = other two cases (rather than not processed). =20 >>>=20 >>>>=20 >>>> BTW to be consistent with other LISP document you should use "LISP = Cache=E2=80=9D instead of =E2=80=9Cmap-cache=E2=80=9D (in the whole = document). >>>>=20 >>>>=20 >>> ok. With the change above we don't use the word map-cache anymore in = the document. So this is addresses as well. >>>=20 >>> Thanks! >>> Fabio >>>=20 >>>=20 >>>=20 >>>> [snip] >>>>=20 >>>=20 >>> >>=20 >=20 --Apple-Mail=_25CE40F6-3506-4EAA-8CDF-F92BF096485D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 3 Nov 2016, at 00:24, Fabio Maino <fmaino@cisco.com> = wrote:

=20 =20
On 11/2/16 9:02 AM, Luigi Iannone wrote:
Hi Fabio,

I went through the last version of the = document.

I still think that in a few place SHOULD should be replaced by MUST. But it is just  my point of view. You can leave SHOULD.

There are just few residual issues:

- Introduction: The second sentence is not = coherent with the first one. The concept of EID-to-RLOC mappings as not been introduced so starting the sentence with =E2=80=9CThese = EID-to-RLOC mapping s=E2=80=A6=E2=80=9D is pretty unclear. I would suggest = you add another sentence.

- Section 7 IANA Considerations: For almost all of the registries the value =E2=80=9C0=E2=80=9D has a special = meaning that this demo is defining, hence the =E2=80=9Cdefined in=E2=80=9D field = should state =E2=80=9Cthis memo=E2=80=9D

- - Section 7 IANA Considerations: The section is not yet 5226 compliant. More specifically, you have to state for each registry how new values are allocated (e.g. FCFS, expert review, etc..)

Thanks Luigi,
do you have any suggestion for the best policy to use for allocation of unassigned values?

It seems to me that given the experimental nature of the draft, for all of the registries created, we could require that 'unassigned values are to be assigned according to the "Specification Required" policy defined in [RFC5226].'


Hi,


I have no strong opinion on the issue. To be = honest, since the size of the fields are pretty big considered their = potential use I would simply go for a FCFS.
Even if some = values are wasted there is a large space. 

If instead you want to be sure to always have = something meaningful, without introducing heavy machinery, I would go = for =E2=80=9CExpert Review=E2=80=9D.

Ciao

L.



  

Fabio





Check again the nits:

 Checking nits according to http://www.ietf.org/id-info/checklist :
  =
--------------------------------------------------------------------------=
--

  =3D=3D There are 10 instances of lines with non-RFC6890-compliant IPv4
     addresses in the document.  If these are example addresses, they =
should
     be changed.

  Checking references for intended status: Experimental
  =
--------------------------------------------------------------------------=
--

  =3D=3D Missing Reference: 'RFC4634' is mentioned on line 840, but not =
defined

  ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)


The above nits reminds me of another issue that = the IESG will certainly raise: can we have all the examples in IPv6 only?
The latest directives are that either you use both v4 and v6 or v6-only, but NOT v4-only.

Thanks

ciao

L.




On 27 Oct 2016, at 23:48, Fabio Maino <fmaino@cisco.com> wrote:

Luigi,
I agree with all the comments.

The document attached should reflect all your suggestions.

A few notes below, just to explicitly ack the changes you suggested.


On 10/26/16 2:13 AM, Luigi Iannone wrote:
=
Hi Fabio,

Yes we are converging, very few points are left. 

Inline are my comments, I snipped everything that we already agreed up on.

L.

On 26 Oct 2016, at 02:14, Fabio Maino <fmaino@cisco.com> wrote:


[snip]




Also, what is the MS stubbornly insists in using an algorithm that the ITR does not support?

The MS might not have alternatives, as it might only support one algorithm.


Sure

The question is: can we have situations in which MS replies always with the same algorithm (because has no alternatives) and the ITR is never able to understand that reply (because has no alternatives).

=46rom my understanding this can happen, right? 

LISP-SEC has no way to prevent it, right?

What is needed is a policy like = =E2=80=9CITR tries using all of the algorithm it supports and then gives up=E2=80=9D, right?

If the answer to those questions = is yes, then IMO this should be spelled out somewhere.



got it. Agreed.




[snip]




   The KDF ID field, =
specifies the suggested key derivation function to
   be used by the Map-Server to derive the MS-OTK.

What happens if the MS will choose a KDF ID not supported by the ITR?
Can you clarify how to solve this situation or explain why this will never = happen?

This is described a few paragraphs below:
" 
If the =
KDF ID in the Map-Reply does not match the
   KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
   Reply and send, at the first opportunity it needs to, a new Map-
   Request with a different KDF ID, according to ITR's...
"


This does not = guarantee that the MS will reply with something the ITR = understands=E2=80=A6.

For some local ITR's policy it may not be guaranteed. It's a balance between reachability and security that the ITR will have to choose.


I am not sure I understand your reply.

My point was the same as above: = what if MS and ITR are not able to talk?

ok. So this is addressed by the same fix used for the previous comment. I'll specify that the ITR will stop re-sending map-requests once all HMAC IDs supported by the ITR have been attempted.
 










   The EID-AD length is =
set to 4 bytes, since the Authentication Data
   does not contain EID-prefix Authentication Data, and the EID-AD
   contains only the KDF ID field.

   In response to an encapsulated Map-Request that has the S-bit set, an
   ITR MUST receive a Map-Reply with the S-bit set, that includes an
   EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
   ITR MUST discard it.  In response to an encapsulated Map-Request with
   S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
   the ITR SHOULD discard the Map-Reply if the S-bit is set.
Why a =E2=80=9CSHOULD=E2=80=9D? = If the Map-Request has S-bit=3D0 = it mean that there is no AD, hence no OTK, how can the ITR decrypt the = reply?????
It MUST discard=E2=80=A6..

If S-bit =3D 0 there's no Authentication Data. The Map-reply is in clear, and can be read.

I am not sure you understood my point.

You send a Map-Request with S=3D0, hence unenbcrypted. How can you possible receive a Map-Reply with S=3D1?
How is it encrypted if the ITR did not provide any = OTK?

Misconfiguration, bugs? I was just trying to enumerate the behaviors of the ITR. There's probably something wrong, and the map-reply should be discarded. Still the mapping is readable, so an ITR favoring reachability may decide to use the mapping.
=

Oh=E2=80=A6 I may see the = misunderstanding. You are saying that the bit is set in the Map-Reply, but actually the content is not encrypted, right? SO the ITR can decide whether or not to use it.

Is that right?

right.



[snip]
I think = =E2=80=9Clog message" is too much implementation = specific. 
If there is = a notification, and how this notification is done, is implementation specific IMHO.
ok. Same as above. 
   The EID-record with =
EID-prefix 1.1.2.0/24 is stored in the map-cache
   because it matches the second EID-prefix contained in the EID-AD.

   The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
   is not included in any of the EID-ADs signed by the Map-Server.  A
   log message is issued.
I think = =E2=80=9Clog message" is too much implementation = specific. 
If there is = a notification, and how this notification is done, is implementation specific IMHO.
ok. Same as above 
  In this last example =
the ETR is trying to
   over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
   only 1.2.3.0/24, hence the EID-record is discarded.
Reading the example I am not sure I would follow this behaviour.
Only 1 = record out of 3 is valid so why should I actually trust the ETR instead of throwing everything = away?
Can you explain ???
The other two records are validated by the MS, so there is no reason to throw those away. =

Yes, but the ETR is still trying to cheat on the third one=E2=80=A6.
So the ETR may be compromised, why should I send traffic to him???

ITR has flagged the security exception with the log entry, and some local ITR policy will decide what to do (including stop encapsulating to the ETR, if that's what is specified by the policy).  At the LISP = level LISP-SEC has done its job: verified = mapping  goes into the map-cache, overclaimed mapping is dropped.


This is not what the above text states. The text states that the valid EID-record is stored in the map-cache.
To be consistent with your reply = you should change and state that the EID-record is eligible to be used by the ITR.


got it. I changed 'stored into the map-cache' with 'eligible to be used by the ITR'. For consistency I have used similar language for the other two cases (rather than not processed). 


BTW to be consistent with other = LISP document you should use "LISP Cache=E2=80=9D = instead of =E2=80=9Cmap-cache=E2=80=9D (in the whole = document).


ok. With the change above we don't use the word map-cache anymore in the document. So this is addresses as well.

Thanks!
Fabio



[snip]


<Diff_ draft-ietf-lisp-sec-11.txt - draft-ietf-lisp-sec-12b.txt.html><draft-ietf-lisp-sec-12b.txt>



= --Apple-Mail=_25CE40F6-3506-4EAA-8CDF-F92BF096485D-- From nobody Fri Nov 4 09:12:18 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C96F12953A; Fri, 4 Nov 2016 09:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmTgty-piZWF; Fri, 4 Nov 2016 09:12:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501451295AF; Fri, 4 Nov 2016 09:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3599; q=dns/txt; s=iport; t=1478275933; x=1479485533; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GXp7yUjBvyYJw2IqFsGE8FPBo4qk+brrva+1GgGZqXI=; b=Tw0scMJBM/uxvr+zCdMveujtt8arhVnUUxpQKVh4wNDvetmhXAmYuPv1 TKYeeDq76Ya89dA2n1Bh/MH5GJY+okHSY53uvJP33V/siQXLUxc0wujIZ xbDfZYU3myjHWV3AgN1KF2FXlyafnQY6d0uFM5sx5Y73qW8WI0pPYyesg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AQCnshxY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAXcqUo04lwCSN4IPgggohXsCglUUAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBBCMVQRALGAICJgICVwYBDAgBAYhUDq8yjHMBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQmFNoF9CIJQhBkRAYMgglwFiEuRWIY0igwCgWyEb4MYhhWNIYQEHjd?= =?us-ascii?q?ZCgmDXIFGPTQBhTkNFweCDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,444,1473120000"; d="scan'208";a="689425013" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 16:12:11 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uA4GCA44025828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Nov 2016 16:12:10 GMT To: Stephen Farrell , The IESG References: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> <74bb00ca-b694-95ea-48a8-4241e3eb7e38@cisco.com> <14cddbee-ebf4-6eeb-e772-4ef6f550f28b@cs.tcd.ie> From: Anton Smirnov Organization: Cisco Systems Message-ID: <29496480-ebe1-2c3d-4ba5-2f814774f5f1@cisco.com> Date: Fri, 4 Nov 2016 17:12:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <14cddbee-ebf4-6eeb-e772-4ef6f550f28b@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:12:16 -0000 Hi Stephen, will it be OK if we mark in the document security algorithm 1 as reserved without even elaborating that it is/was RSA-SHA1 and the only security algorithm specified in the RFC will be 2 == RSA-SHA256 ? This will ensure that whoever is using algorithm 1 will not run into compatibility issues but RSA-SHA1 will be clearly non-RFC-compliant. Anton On Tuesday 01 November 2016 22:09, Stephen Farrell wrote: > Hiya, > > On 01/11/16 18:51, Anton Smirnov wrote: >> Hello Stephen, >> >> thanks for your comment. >> >> Existing DDT implementations are already using RSA-SHA1, so we cannot >> simply replace it with RSA-SHA256. But we should be able to add the >> latter as another signing algorithm. > Really? The sha-1 weaknesses for use in signatures were > found and documented in an RFC in 2005. [1] We published > an RFC attempting to tidy up remaining loose ends related > to sha1 for signatures in 2011. [2] Asking for rsa-sha1 now > is really very far behind the state of the art. > > But are you talking implementations or deployments here? > If mostly the former then I think you ought remove rsa-sha1 > entirely and replace with rsa-sha256. That is a trivial > code change and I can see no justification for not making > that change. > > If you are talking about existing deployments please > provide the argument as to why those are such that we > should publish an RFC that calls for use of an obsolete > signature algorithm 11 years after the initial crypto > weaknesses were documented in the IETF. If there are good > arguments for that a) I'll be surprised, and b) my plan > would be to ask for advice from the security area - I > don't think we've hit this case before where an experimental > RFC wants to use such a thoroughly obsolete signature > algorithm, one that would never be ok in a standards > track RFC and one where it's really easy to do the right > thing instead. > > Cheers, > S. > > [1] https://tools.ietf.org/html/rfc4270 > [2] https://tools.ietf.org/html/rfc6194 > > >> Authors will take in your comments in the next revision of the draft. >> >> Anton >> >> On Thursday 27 October 2016 14:44, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-lisp-ddt-08: 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-ddt/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> 6.4.1: RSA-SHA1 is not the right choice today, shouldn't >>> this be RSA-SHA256? >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - 6.4.1: Can you clarify what bits are signed? I'm not >>> quite sure from the description given - you can have >>> more than one signature but you say the the "entire >>> record" is covered. >>> >>> - Section 8: Where's signature validation in the >>> pseudo-code? >>> >>> From nobody Fri Nov 4 09:15:17 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1BB12959B for ; Fri, 4 Nov 2016 09:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDGW3ZhHVsuJ for ; Fri, 4 Nov 2016 09:15:10 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD5A12950D for ; Fri, 4 Nov 2016 09:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46962; q=dns/txt; s=iport; t=1478276110; x=1479485710; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=t9I8dgs6x0YD1eYWVQwifeCVrpvHpXLTv1IbDO4O1ZE=; b=eFZhEVvZ+5iemo/1OEliBqFOTjGcEOD9BWUY8JhF0SNbzeV2ViaCZEW5 a+sDR9G6bSz7D7hq279XaoEUT4XT10XHJ9dSPQWEzCBH18JPFJR0gAaqr I+8Nw2U0OvaImg9nDvIC5tuDEL+e1eAg9273UdBEbP7vD9GoN9BQrLs2v 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAQC8shxY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAXcqA0+DAYo3lwCMNYgRggUDHQuFewKCVRQBAgEBAQE?= =?us-ascii?q?BAQFiKIRiAQEEAQEBCQ4BCA8BBTYEBxAJAhICBAICJgICJyIOBg0GAgEBBRCIP?= =?us-ascii?q?w6Rc50/jHMBAQEBAQEBAwEBAQEBAQEBH4EJhTaBfQiBS4EFhDGDGoJcBYhLhgi?= =?us-ascii?q?LUIY0gkdEhwGBbk6EIYMYI4VyiRyEBYQEHjdZCgmDJQIBHIFePTQBhTcFAoI1A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.31,444,1473120000"; d="scan'208";a="646865689" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 16:15:05 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA4GF563010191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Nov 2016 16:15:05 GMT To: Dino Farinacci References: <87bmym4cyp.fsf@hobgoblin.ariadne.com> <50795FAC-6560-4F02-937B-F6343F1E6CF7@gmail.com> <0099C88F-59F0-4201-9518-214D525342C4@gmail.com> From: Anton Smirnov Organization: Cisco Systems Message-ID: <73e5e11d-be94-7496-b2f9-e3c45445def0@cisco.com> Date: Fri, 4 Nov 2016 17:15:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0099C88F-59F0-4201-9518-214D525342C4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: Cc: "Dale R. Worley" , LISP mailing list list Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:15:15 -0000 Hi Dino, given the scope of comments and need for review between authors it may be difficult. We will make an effort to achieve this date but right now I can't guarantee this. Anton On Tuesday 01 November 2016 22:55, Dino Farinacci wrote: > Great to hear. Is the goal to publish the new draft on Monday of IETF week? > > Dino > >> On Nov 1, 2016, at 11:47 AM, Anton Smirnov wrote: >> >> Hello Dino, >> >> thanks for taking time to answer these concerns. Authors will work on the revised text to incorporate those points. >> >> Anton >> >> On Sunday 16 October 2016 22:43, Dino Farinacci 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 >>>> . >>>> >>>> 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. >>> Thanks for the review Dale. Your comments are outstanding! And your suggestions even better. ;-) >>> >>> I am not an author but was involved in the LISP-DDT design early on so I would like to respond to some of your comments. Where I think text should change, I will suggest that to help the authors. To clarify understanding, I will comment inline. >>> >>> One of the authors will make the changes. >>> >>>> * 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: >>> Yes, you interpreted the defintion of an extended-EID correctly. It is a multi-tuple entity that has hierarchy so we can delegate any tuple, as well as the tuple itself, downward on the tree. >>> >>>> In section 3, definition "XEID-prefix" seems to assume that an >>>> XEID-prefix will always contain a complete DBID, IID, and AFI. >>> For a lookup yes. For a delegation, it can be any part of it as I explained above. >>> >>>> 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. >>> Well it is authoriative for everything, by default, but a Map-Referral return code will tell you exactly what it is authoritative for if configured for specficy XEIDs. >>> >>>> 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. >>> Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), it would be the delegation represents all prefixes in all address families. >>> >>> We should clarify that in the text. >>> >>>> 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. >>> I think we don’t need to say how its initialized IMO. We should change text here. >>> >>>> * 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. >>> Agree. We should make this change. >>> >>>> 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. >>> Experience has showed us that running parallel mapping databases will be useful. They really don’t need to be numbered or identified because there will be distinct roots and xTRs can connect to one or multiple of them. >>> >>> And right now, we do not have an encoding for a DBID that can be sent in a Map-Register or Map-Request. So I am agreeing with you. >>> >>>> 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. >>> Well no, not insane, if we required IID for every register and request, then the XEID would have the same set of tuples for all lookups. Supplying an IID=0 is not wrong or bad semantically and just cost 32-bits in message space. >>> >>>> 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. >>> True. Authors use the reference I put in the latest LCAF draft. That was an IESG comment. So we should get it right. >>> >>>> * 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. >>> Should be fixed in the text. Thanks. >>> >>>> * 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. >>> Well RFC6833 defines the "bottom-half” of the map-server. That is the interface for Map-Registration. A Map-Server is also a DDT-node when there are map-server-peer configuration so a set of map-servers that are authoritative and have registeration state for the same prefix can include themselves as referrals in Map-Referral messages. >>> >>>> * 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. >>> The name “Map-Server” in context to LISP-DDT means that it is a DDT-node at the bottom of the tree with no DDT-node children. It is a DDT-node but one with more functionality, Map-Server functionality according to RFC6833. >>> >>>> However, the preceding paragraph assumes that a DDT node is not >>>> allowed to contain both prefix delegations and ETR registrations. >>> Correct. >>> >>>> 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. >>> All correct. You interpreted the idea exactly. >>> >>>> * Is it really true that two Map Servers that are authoritative for >>>> the same XEID prefix can contain different sets of ETR registrations? >>> Typically no. The set of ETRs at a LISP site will register all the ETRs RLOCs for the same EID-prefix. Therefore, each map-server, that all ETRs for that site register to, will have the same EID-prefix-to-RLOC-set mapping. >>> >>>> 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? >>> No, it doens’t have to do that. And it SHOULDN’T that. I can query each referral from a Map-Referral serially or in parallel, only for reachability and robustness reasons. >>> >>>> 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. >>> It is a bit. But leaves out specifics to LISP-DDT because Map-Servers can use any “mapping database transport” system. >>> >>>> * 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 >>> We should have new text to make this more clear. >>> >>>> 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. >>> All good points. Agree. >>> >>>> 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. >>>> >>>> — >>> Agree. >>> >>>> 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. >>> Agree. >>> >>>> 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. >>> I think we should have both. >>> >>>> 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. >>> Agree. >>> >>>> 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. >>> The flag is to tell the difference between a Map-Request that is originated by a LISP-site (ITR or PITR) and one that is sent by a Map-Resolver. One generates a Map-Reply and the other generates a Map-Referral. >>> >>>> 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. >>> That is that the typical case though. Look at it as a Map-Request, with DDT-flag set, as a solitication for a Map-Referral. >>> >>>> 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! >>> Correct. >>> >>>> 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 >>> It can work that way. Do you think calling the bit “Request-for-Map-Referral” would be better? >>> >>>> 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. >>> Or we could call the bit “DDT-client-flag”. And still keep the reference to the bit called “D”. >>> >>>> 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 >>> We should say “more specific information”. Where “more-specific” is relative to the xEID-prefix. >>> >>>> 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. >>> True. We should have new text to make this more clear. >>> >>>> 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 >>> No, not architecturally. It receives only Map-Requests with the DDT-bit set to 0. I say no architecturelly because if the map-resolver is also a map-server, then it could receive DDT Map-Requests. But it is acting as a map-server. >>> >>> DDT-nodes could also be map-resolvers. Which mean they are part of the delegarion hierarchy but also are configured with DDT-roots to send requests. It all comes down to how a network adminstrator would want to co-locate such functions. >>> >>> With the popularity of VMs and containers, the same piece of bare-metal could be both a map-resolver and DDT-node, but from a LISP architecture point of view, they are separate nodes (with separate IP addresses). >>> >>>> 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. >>> DDT-Map-Requests to not get sent to Map-Resolvers and we should make that crystal clear. >>> >>>> 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). >>> Map-Servers configured as a DDT-node is definitely part of DDT because they must send MS-ACK based Map-Referrals. Because if this does not happen, then Map-Resolvers will retransmit and think they have not got to the bottom of the referral tree. >>> >>>> 6.1. Action codes >>>> >>>> MS-ACK (2): indicates that a replying DDT Map Server received a DDT >>>> >>>> s/a replying/the replying/ >>> Agree. >>> >>>> 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. >>> To be honest, I am questioning the value of “hint” as a reference. Hmm. Let’s see what the authors think about this. >>> >>>> 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. >>> Agree. >>> >>>> 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. >>> We don’t want to add an additional set of comabinations for hints and non-hints. Authors, we should discuss this. >>> >>>> 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. >>> All this is trying to say (and with too many words), is that the referral-set is stored in a Map-Referral as RLOC-records. That is all. >>> >>>> 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. >>> Needs to be fixed in the text. >>> >>>> 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. >>> The signature covers the complete Map-Referral message. If that is not clear, we will make it clear. >>> >>>> 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. >>> It allows the implementation to be more efficient. You build the message once with the correct length include the signature records, run the hash over it. And then fill in the zero bit fields. That way you can then include the referral addresses that are part of the LCAF. >>> >>>> Is it a problem that Original Record TTL, Signature Expiration, and >>>> Signature Inception aren't protected by the signature? >>> The entire Map-Referral should be covered 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. >>> See my explanations above. >>> >>>> 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. >>> Agree. >>> >>>> 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 >>> True, in the DDT case as well. >>> >>>> 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. >>> But that isn’t precisely true. Delegations ARE configuration items, in DDT-nodes, all of roots, ddt-nodes, and map-servers. And the cache is dynamically created entries from Map-Referrals from those node’s configuration information. >>> >>>> 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 >>> No, they would be. >>> >>>> 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. >>> We have to simplify this wording. It is more complex than it needs to be. >>> >>>> 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 >>> No, both. Because map-resolvers need to know where to send DDT-Map-Requests and when they get signed Map-Referrals, then need a public key to verify the signature. And the reason is beacuse there is no parent of the root that can give the map-resolver the public-key like the rest of the hierarchy can do. >>> >>>> 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. >>> Yes, yes, yes. >>> >>>> 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”. >>> Really good point. >>> >>>> 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”. >>> Right. >>> >>>> 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. >>> Agree. The Map-Resolver does send a response. If its not documented, we missed it and will add. >>> >>>> MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same >>>> manner >>>> >>>> It might be better to say "processes" than "follows”. >>> Agree. >>> >>>> 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. >>> You are absolutely right. There needs to be a complete example of the “day in the life of a Map-Request” when the Map-Resolver has nothing cached and the ITR and ETR are not DDT-clients. That is the typical use-case that has been and will continue to be deployed. >>> >>>> 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. >>> LISP-SEC information is in the Map-Request from the ITR, transported in the DDT-Map-Request so an ETR can get the LISP-SEC information in the Map-Request to then return LISP-SEC in the *Map-Reply*. >>> >>> The Map-Server only sends Map-Replies when it is configured to proxy-reply and the ETR is not in the loop here. And it would fill in the same LISP-SEC information the ETR would because the registration information is the same as the database entry info the ETR has stored. >>> >>>> 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”. >>> It means the DDT-Map-Request went all the way to the map-server, it has a a configure LISP site entry and the ETRs have not registered (yet). >>> >>>> 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 >>> A response is ALWAYs returned in LISP-DDT. The only time it can’t is when a Map-Request cannot get to where its going or the Map-Referral cannot get back to the DDT-client source. And that is the only case we call a “timeout”. >>> >>>> 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. >>> Agree. We should have new text to make this more clear. >>> >>>> 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: >>> Yes, because each parent points to 2 children. >>> >>>> +---------------------+ +---------------------+ >>>> | 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/ >>> Agree. >>> >>>> 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. >>> Agree. >>> >>>> 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. >>> Really good point. I definitely agree. >>> >>>> 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. >>> It should yes. >>> >>>> 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. >>> An RLOC record contains LCAF type 11 with the RLOC/address of the referral and key material. >>> >>>> 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. >>> Agree. >>> >>>> 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. >>> We have referred to LISP-DDT-SEC to mean the public/private key signing of Map-Referral messages. That is what the reference to DDT security could mean. But this section could be confidentiality support as well. >>> >>>> 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). >>> Should be normative since we are about to publish the LCAF RFC. >>> >>>> [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, >>>> >>> 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, . >>>> >>>> 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. >>> Agree. >>> >>>> Dale >>> Thanks again for the really detailed comments. >>> >>> Dino >>> >>> >>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp From nobody Fri Nov 4 09:27:06 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569E41294EA; Fri, 4 Nov 2016 09:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDPfGdzel3w8; Fri, 4 Nov 2016 09:27:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6511295B1; Fri, 4 Nov 2016 09:27:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0093BE4C; Fri, 4 Nov 2016 16:27:01 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6m67D0WooVt; Fri, 4 Nov 2016 16:27:01 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D6CCCBE47; Fri, 4 Nov 2016 16:27:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478276821; bh=vGsqd1PyvO66PZ7+w+5mA/JDGNUGV2A7qCFZwKzOuJY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=n8rnwCgWjLY1XlIQnCDRdUxejonUYrhKNUYV3fKyMKu3IcWk87cFqm54zn3jpLr3F HStugz2Rw7j56VJPueqBMryoeP/9oEuFzVzu0BGNcAAxSR2AmCztsU6pg3YLhEIicH +kuUj/EVy5kiQ6ragWO7Smu2gOmd3cyrxWvoc5pc= To: Anton Smirnov , The IESG References: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> <74bb00ca-b694-95ea-48a8-4241e3eb7e38@cisco.com> <14cddbee-ebf4-6eeb-e772-4ef6f550f28b@cs.tcd.ie> <29496480-ebe1-2c3d-4ba5-2f814774f5f1@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <70451832-0828-3108-9f9c-1c706eb1322d@cs.tcd.ie> Date: Fri, 4 Nov 2016 16:27:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <29496480-ebe1-2c3d-4ba5-2f814774f5f1@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060301050709040508030906" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:27:05 -0000 This is a cryptographically signed message in MIME format. --------------ms060301050709040508030906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/11/16 16:12, Anton Smirnov wrote: > Hi Stephen, >=20 > will it be OK if we mark in the document security algorithm 1 as > reserved without even elaborating that it is/was RSA-SHA1 and the only > security algorithm specified in the RFC will be 2 =3D=3D RSA-SHA256 ? >=20 > This will ensure that whoever is using algorithm 1 will not run into= > compatibility issues but RSA-SHA1 will be clearly non-RFC-compliant. How about defining alg=3D1 as rsa-sha1 and marking that as deprecated with alg=3D2 as rsa-sha256 as the MUST implement? (I don't care myself if you have an IANA registry for those yet or not, doing it in text is fine.) S >=20 > Anton >=20 > On Tuesday 01 November 2016 22:09, Stephen Farrell wrote: >> Hiya, >> >> On 01/11/16 18:51, Anton Smirnov wrote: >>> Hello Stephen, >>> >>> thanks for your comment. >>> >>> Existing DDT implementations are already using RSA-SHA1, so we can= not >>> simply replace it with RSA-SHA256. But we should be able to add the >>> latter as another signing algorithm. >> Really? The sha-1 weaknesses for use in signatures were >> found and documented in an RFC in 2005. [1] We published >> an RFC attempting to tidy up remaining loose ends related >> to sha1 for signatures in 2011. [2] Asking for rsa-sha1 now >> is really very far behind the state of the art. >> >> But are you talking implementations or deployments here? >> If mostly the former then I think you ought remove rsa-sha1 >> entirely and replace with rsa-sha256. That is a trivial >> code change and I can see no justification for not making >> that change. >> >> If you are talking about existing deployments please >> provide the argument as to why those are such that we >> should publish an RFC that calls for use of an obsolete >> signature algorithm 11 years after the initial crypto >> weaknesses were documented in the IETF. If there are good >> arguments for that a) I'll be surprised, and b) my plan >> would be to ask for advice from the security area - I >> don't think we've hit this case before where an experimental >> RFC wants to use such a thoroughly obsolete signature >> algorithm, one that would never be ok in a standards >> track RFC and one where it's really easy to do the right >> thing instead. >> >> Cheers, >> S. >> >> [1] https://tools.ietf.org/html/rfc4270 >> [2] https://tools.ietf.org/html/rfc6194 >> >> >>> Authors will take in your comments in the next revision of the >>> draft. >>> >>> Anton >>> >>> On Thursday 27 October 2016 14:44, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-lisp-ddt-08: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> 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-ddt/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> 6.4.1: RSA-SHA1 is not the right choice today, shouldn't >>>> this be RSA-SHA256? >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> - 6.4.1: Can you clarify what bits are signed? I'm not >>>> quite sure from the description given - you can have >>>> more than one signature but you say the the "entire >>>> record" is covered. >>>> >>>> - Section 8: Where's signature validation in the >>>> pseudo-code? >>>> >>>> >=20 --------------ms060301050709040508030906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDQx NjI3MDBaMC8GCSqGSIb3DQEJBDEiBCB6YeD9GIAYTemOatU415e8RiZIEOBTYGfY7+A9h67u TDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAQGCkLIHaDFj3s1lbHHQ6x/Y6ROYDRwxROvCKZ4WWfySDfs2KyPcJm JaQNmI82PpM3xT9aFOtPlbiz77UizT6Et0XtjPowvtufMX+LY8xaEQUe6Xd3pXjyqcrcax7k NEJr1A6lS2nWb8FQeid1SYJhyoeIwIRkYXZG0OhUOxZSbwkwPCSaZRufkMfffhJyLTzqNyBX 9SvxdYl/MUxUzNM8YLD8uCIhgRciKs0XsAhvPR7AQ/rQa7JgUx5QY5+bUTaBkQgBwnyUBldD Kr6eniX0YJbNjnZq8Pz+BjGIKEmvZVXPuKdD56h6Uo3kz4BKjyrLQMVk8J1+CqZBd+4OGViP AAAAAAAA --------------ms060301050709040508030906-- From nobody Fri Nov 4 10:24:43 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90F0129505 for ; Fri, 4 Nov 2016 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dM23a68EXc7 for ; Fri, 4 Nov 2016 10:24:36 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAD712949B for ; Fri, 4 Nov 2016 10:24:36 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 189so55131857pfz.3 for ; Fri, 04 Nov 2016 10:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aW97/F3dIyn19mdgrRKnrjBO3oVCEQ8Y7ciJ1eEEVXE=; b=W0qnI5zxt/op9ytnpGG5ZSSjZ2XzJgNThWrrby+zAb4Aa39gMEx39gbhoBLl2kAe3Z MEJ4FsA8HTGOiJwSSQ5JdgwD5jckV8GODK6wo/3+PrCd+WuhOrj1zMWs/RdjTDFtTLdX b+lxB4bmfWUxHJyTZiYjl6bWCjkQS8XKINj255OB9hkzTcWo7GCCQ3oOivw89vp7i75Q wzJ65ECKUlXfyrZRTFEmxFKezXoGP9Tpd+upcjQWOSLkSi4B1SZAx8+Qw9FpbhAQuSwu zbwk9U4/okXkPAvstOaCVibPqJgIhzTmAQeoK1RcyknaoF5wu3llz1KL0RhPoQt/fDX5 klHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aW97/F3dIyn19mdgrRKnrjBO3oVCEQ8Y7ciJ1eEEVXE=; b=ixDbmZNIyXxRTdZD7ZHDlfPeC79y2Op0EfgMPMr/5dIPyU7rzT7EU1RJtPoVtXCe5f NpeZAJc0KT2e6XzY2B61hJbw352Rawgzzocg7a48OYRing202ggvbV5citD4PV+Bh+VU Qcbn4f6dmthCK1rqwmqaIvY+178eQE9SQs0Sz7ayaEaWPk49hELtFUiZ5P6wHXMRrg1q cy/joUyCsaBAxLJ6YY72rpg/H8J82gm31NZrl5Y0zeZwk8EiFYQlo72wuFLDRWl3SQA3 cFK6sjLYRIgLgkGGoGyYxQ2jeHpK+PMYquFiP2oLZfVZPJ9aIJ9RIGiHJGJjkg87NKmU M/2g== X-Gm-Message-State: ABUngvfPuipavRHuHwoPz2QzD2lWqbEHMxI58rM1AFS/45hvypt7Inj5aohAm38UORiolQ== X-Received: by 10.98.66.77 with SMTP id p74mr28726665pfa.15.1478280274475; Fri, 04 Nov 2016 10:24:34 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id tx10sm21856035pab.40.2016.11.04.10.24.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 10:24:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <73e5e11d-be94-7496-b2f9-e3c45445def0@cisco.com> Date: Fri, 4 Nov 2016 10:24:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F5BC459-2446-4DF9-8D22-53389476C620@gmail.com> References: <87bmym4cyp.fsf@hobgoblin.ariadne.com> <50795FAC-6560-4F02-937B-F6343F1E6CF7@gmail.com> <0099C88F-59F0-4201-9518-214D525342C4@gmail.com> <73e5e11d-be94-7496-b2f9-e3c45445def0@cisco.com> To: Anton Smirnov X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "Dale R. Worley" , LISP mailing list list Subject: Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:24:41 -0000 Okay, thanks for the effort. Dino > On Nov 4, 2016, at 9:15 AM, Anton Smirnov wrote: >=20 > Hi Dino, >=20 > given the scope of comments and need for review between authors it = may be difficult. We will make an effort to achieve this date but right = now I can't guarantee this. >=20 > Anton >=20 > On Tuesday 01 November 2016 22:55, Dino Farinacci wrote: >> Great to hear. Is the goal to publish the new draft on Monday of IETF = week? >>=20 >> Dino >>=20 >>> On Nov 1, 2016, at 11:47 AM, Anton Smirnov = wrote: >>>=20 >>> Hello Dino, >>>=20 >>> thanks for taking time to answer these concerns. Authors will work = on the revised text to incorporate those points. >>>=20 >>> Anton >>>=20 >>> On Sunday 16 October 2016 22:43, Dino Farinacci 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. >>>>>=20 >>>>> For more information, please see the FAQ at >>>>> . >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Summary: This draft is on the right track but has open issues, >>>>> described in the review. >>>> Thanks for the review Dale. Your comments are outstanding! And your = suggestions even better. ;-) >>>>=20 >>>> I am not an author but was involved in the LISP-DDT design early on = so I would like to respond to some of your comments. Where I think text = should change, I will suggest that to help the authors. To clarify = understanding, I will comment inline. >>>>=20 >>>> One of the authors will make the changes. >>>>=20 >>>>> * 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: >>>> Yes, you interpreted the defintion of an extended-EID correctly. It = is a multi-tuple entity that has hierarchy so we can delegate any tuple, = as well as the tuple itself, downward on the tree. >>>>=20 >>>>> In section 3, definition "XEID-prefix" seems to assume that an >>>>> XEID-prefix will always contain a complete DBID, IID, and AFI. >>>> For a lookup yes. For a delegation, it can be any part of it as I = explained above. >>>>=20 >>>>> In section 4.2.1: >>>>>=20 >>>>> The root DDT node is the logical "top" of the database = hierarchy: >>>>> DBID=3D0, IID=3D0, AFI=3D0, EID-prefix=3D0/0. >>>>>=20 >>>>> But really, the condition of a root node is that it's = authoritative >>>>> for the *empty* XEID-prefix. >>>> Well it is authoriative for everything, by default, but a = Map-Referral return code will tell you exactly what it is authoritative = for if configured for specficy XEIDs. >>>>=20 >>>>> 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. >>>> Right, if a delegation is configured with solely the 2-tuple = (DBID=3D0, IID=3D0), it would be the delegation represents all prefixes = in all address families. >>>>=20 >>>> We should clarify that in the text. >>>>=20 >>>>> 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: >>>>>=20 >>>>> the "referral XEID-prefix" is also initialized to the null value >>>>> since no referral has yet been received. >>>> I think we don=E2=80=99t need to say how its initialized IMO. We = should change text here. >>>>=20 >>>>> * 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. >>>> Agree. We should make this change. >>>>=20 >>>>> 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. >>>> Experience has showed us that running parallel mapping databases = will be useful. They really don=E2=80=99t need to be numbered or = identified because there will be distinct roots and xTRs can connect to = one or multiple of them. >>>>=20 >>>> And right now, we do not have an encoding for a DBID that can be = sent in a Map-Register or Map-Request. So I am agreeing with you. >>>>=20 >>>>> IID is presumably expected to be zero except when VPNs are used. = (see >>>>> definition "Extended EID (XEID)") >>>>>=20 >>>>> 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. >>>> Well no, not insane, if we required IID for every register and = request, then the XEID would have the same set of tuples for all = lookups. Supplying an IID=3D0 is not wrong or bad semantically and just = cost 32-bits in message space. >>>>=20 >>>>> 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. >>>> True. Authors use the reference I put in the latest LCAF draft. = That was an IESG comment. So we should get it right. >>>>=20 >>>>> * 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. >>>> Should be fixed in the text. Thanks. >>>>=20 >>>>> * 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. >>>> Well RFC6833 defines the "bottom-half=E2=80=9D of the map-server. = That is the interface for Map-Registration. A Map-Server is also a = DDT-node when there are map-server-peer configuration so a set of = map-servers that are authoritative and have registeration state for the = same prefix can include themselves as referrals in Map-Referral = messages. >>>>=20 >>>>> * 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. >>>> The name =E2=80=9CMap-Server=E2=80=9D in context to LISP-DDT means = that it is a DDT-node at the bottom of the tree with no DDT-node = children. It is a DDT-node but one with more functionality, Map-Server = functionality according to RFC6833. >>>>=20 >>>>> However, the preceding paragraph assumes that a DDT node is not >>>>> allowed to contain both prefix delegations and ETR registrations. >>>> Correct. >>>>=20 >>>>> 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. >>>> All correct. You interpreted the idea exactly. >>>>=20 >>>>> * Is it really true that two Map Servers that are authoritative = for >>>>> the same XEID prefix can contain different sets of ETR = registrations? >>>> Typically no. The set of ETRs at a LISP site will register all the = ETRs RLOCs for the same EID-prefix. Therefore, each map-server, that all = ETRs for that site register to, will have the same = EID-prefix-to-RLOC-set mapping. >>>>=20 >>>>> 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? >>>> No, it doens=E2=80=99t have to do that. And it SHOULDN=E2=80=99T = that. I can query each referral from a Map-Referral serially or in = parallel, only for reachability and robustness reasons. >>>>=20 >>>>> 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. >>>> It is a bit. But leaves out specifics to LISP-DDT because = Map-Servers can use any =E2=80=9Cmapping database transport=E2=80=9D = system. >>>>=20 >>>>> * 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 >>>> We should have new text to make this more clear. >>>>=20 >>>>> 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. >>>> All good points. Agree. >>>>=20 >>>>> 1. Introduction >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> 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. >>>>>=20 >>>>> =E2=80=94 >>>> Agree. >>>>=20 >>>>> It >>>>> also provides delegation information to Map Resolvers, which use = the >>>>> information to locate EID-to-RLOC mappings. >>>>>=20 >>>>> 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 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> and approximately all uses of "Map Resolver" should be changed to = "DDT >>>>> client". >>>>>=20 >>>>> LISP-DDT defines a new device type, the DDT node, that is = configured >>>>> as authoritative for one or more XEID-prefixes. >>>>>=20 >>>>> 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. >>>> Agree. >>>>=20 >>>>> 3. Definition of Terms >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> These can be simplified by moving the details of the XEID format = and >>>>> the values of the fields into separate paragraphs (as discussed >>>>> above). >>>>>=20 >>>>> DDT node: a network infrastructure component responsible for >>>>> specific XEID-prefix and for delegation of more-specific sub- >>>>> prefixes to other DDT nodes. >>>>>=20 >>>>> 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)". >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> I think we should have both. >>>>=20 >>>>> 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 ... >>>>>=20 >>>>> Given the importance of Map-Request messages, it might be worth >>>>> mentioning that they are defined in RFC 6830. >>>> Agree. >>>>=20 >>>>> 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. >>>> The flag is to tell the difference between a Map-Request that is = originated by a LISP-site (ITR or PITR) and one that is sent by a = Map-Resolver. One generates a Map-Reply and the other generates a = Map-Referral. >>>>=20 >>>>> 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. >>>> That is that the typical case though. Look at it as a Map-Request, = with DDT-flag set, as a solitication for a Map-Referral. >>>>=20 >>>>> Also, the definition of the flag in section 5 is awkward: >>>>>=20 >>>>> 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]. >>>>>=20 >>>>> 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! >>>> Correct. >>>>=20 >>>>> 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 >>>> It can work that way. Do you think calling the bit = =E2=80=9CRequest-for-Map-Referral=E2=80=9D would be better? >>>>=20 >>>>> 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. >>>> Or we could call the bit =E2=80=9CDDT-client-flag=E2=80=9D. And = still keep the reference to the bit called =E2=80=9CD=E2=80=9D. >>>>=20 >>>>> 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; >>>>>=20 >>>>> 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 >>>> We should say =E2=80=9Cmore specific information=E2=80=9D. Where = =E2=80=9Cmore-specific=E2=80=9D is relative to the xEID-prefix. >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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). >>>>>=20 >>>>> 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. >>>> True. We should have new text to make this more clear. >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>> No, not architecturally. It receives only Map-Requests with the = DDT-bit set to 0. I say no architecturelly because if the map-resolver = is also a map-server, then it could receive DDT Map-Requests. But it is = acting as a map-server. >>>>=20 >>>> DDT-nodes could also be map-resolvers. Which mean they are part of = the delegarion hierarchy but also are configured with DDT-roots to send = requests. It all comes down to how a network adminstrator would want to = co-locate such functions. >>>>=20 >>>> With the popularity of VMs and containers, the same piece of = bare-metal could be both a map-resolver and DDT-node, but from a LISP = architecture point of view, they are separate nodes (with separate IP = addresses). >>>>=20 >>>>> 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. >>>> DDT-Map-Requests to not get sent to Map-Resolvers and we should = make that crystal clear. >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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). >>>> Map-Servers configured as a DDT-node is definitely part of DDT = because they must send MS-ACK based Map-Referrals. Because if this does = not happen, then Map-Resolvers will retransmit and think they have not = got to the bottom of the referral tree. >>>>=20 >>>>> 6.1. Action codes >>>>>=20 >>>>> MS-ACK (2): indicates that a replying DDT Map Server received a = DDT >>>>>=20 >>>>> s/a replying/the replying/ >>>> Agree. >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> To be honest, I am questioning the value of =E2=80=9Chint=E2=80=9D = as a reference. Hmm. Let=E2=80=99s see what the authors think about = this. >>>>=20 >>>>> 6.3. Incomplete flag >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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". >>>>>=20 >>>>> 6.4. Map-Referral Message Format >>>>>=20 >>>>> 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. >>>> Agree. >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> We don=E2=80=99t want to add an additional set of comabinations for = hints and non-hints. Authors, we should discuss this. >>>>=20 >>>>> 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]. >>>>>=20 >>>>> This paragraph doesn't make sense in this context. The terms = "Loc", >>>>> "keys", "LCAF", "Security material" are all undefined in this = context. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> All this is trying to say (and with too many words), is that the = referral-set is stored in a Map-Referral as RLOC-records. That is all. >>>>=20 >>>>> 6.4.1. SIG section >>>>>=20 >>>>> Sig Length: The length of the Signature field. >>>>>=20 >>>>> Is this measured in bytes? >>>>>=20 >>>>> 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. >>>> Needs to be fixed in the text. >>>>=20 >>>>> 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. >>>> The signature covers the complete Map-Referral message. If that is = not clear, we will make it clear. >>>>=20 >>>>> 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. >>>> It allows the implementation to be more efficient. You build the = message once with the correct length include the signature records, run = the hash over it. And then fill in the zero bit fields. That way you can = then include the referral addresses that are part of the LCAF. >>>>=20 >>>>> Is it a problem that Original Record TTL, Signature Expiration, = and >>>>> Signature Inception aren't protected by the signature? >>>> The entire Map-Referral should be covered by the signature. >>>>=20 >>>>> 7.1.1. Match of a delegated prefix (or sub-prefix) >>>>>=20 >>>>> If the delegation is known to be a DDT Map Server, >>>>>=20 >>>>> 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. >>>> See my explanations above. >>>>=20 >>>>> 7.1.2. Missing delegation from an authoritative prefix >>>>>=20 >>>>> 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. >>>>>=20 >>>>> It would be a bit clearer if "the least-specific XEID-prefix" was >>>>> changed to "the least-specific prefix of the XEID". >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> Agree. >>>>=20 >>>>> 7.3. DDT Map Resolver >>>>> 7.3.1. Queuing and sending DDT Map-Requests >>>>>=20 >>>>> 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 >>>> True, in the DDT case as well. >>>>=20 >>>>> 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. >>>> But that isn=E2=80=99t precisely true. Delegations ARE = configuration items, in DDT-nodes, all of roots, ddt-nodes, and = map-servers. And the cache is dynamically created entries from = Map-Referrals from those node=E2=80=99s configuration information. >>>>=20 >>>>> 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: >>>>>=20 >>>>> The referral cache is initially populated with one or more >>>>> statically-configured entries; >>>>>=20 >>>>> Similarly this is a structural statement about the cache: >>>>>=20 >>>>> A DDT Map Resolver is not absolutely required to cache = referrals, >>>>> but it doing so decreases latency and reduces lookup delays. >>>>>=20 >>>>> -- >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>> No, they would be. >>>>=20 >>>>> 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. >>>> We have to simplify this wording. It is more complex than it needs = to be. >>>>=20 >>>>> 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 >>>> No, both. Because map-resolvers need to know where to send = DDT-Map-Requests and when they get signed Map-Referrals, then need a = public key to verify the signature. And the reason is beacuse there is = no parent of the root that can give the map-resolver the public-key like = the rest of the hierarchy can do. >>>>=20 >>>>> 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. >>>> Yes, yes, yes. >>>>=20 >>>>> 7.3.2. Receiving and following referrals >>>>>=20 >>>>> If the maximum number of retransmissions has occurred and all = RLOCs >>>>> have been tried, then the pending request list entry is = dequeued. >>>>>=20 >>>>> 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". >>>>>=20 >>>>> 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=E2=80=9D= . >>>> Really good point. >>>>=20 >>>>> 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=E2=80=9D. >>>> Right. >>>>=20 >>>>> 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. >>>> Agree. The Map-Resolver does send a response. If its not = documented, we missed it and will add. >>>>=20 >>>>> MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the = same >>>>> manner >>>>>=20 >>>>> It might be better to say "processes" than "follows=E2=80=9D. >>>> Agree. >>>>=20 >>>>> 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 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> You are absolutely right. There needs to be a complete example of = the =E2=80=9Cday in the life of a Map-Request=E2=80=9D when the = Map-Resolver has nothing cached and the ITR and ETR are not DDT-clients. = That is the typical use-case that has been and will continue to be = deployed. >>>>=20 >>>>> 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. >>>> LISP-SEC information is in the Map-Request from the ITR, = transported in the DDT-Map-Request so an ETR can get the LISP-SEC = information in the Map-Request to then return LISP-SEC in the = *Map-Reply*. >>>>=20 >>>> The Map-Server only sends Map-Replies when it is configured to = proxy-reply and the ETR is not in the loop here. And it would fill in = the same LISP-SEC information the ETR would because the registration = information is the same as the database entry info the ETR has stored. >>>>=20 >>>>> 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. >>>>>=20 >>>>> I think "non-registered XEID-prefix" is meant to mean = "least-specific >>>>> prefix of the XEID for which no registrations exist=E2=80=9D. >>>> It means the DDT-Map-Request went all the way to the map-server, it = has a a configure LISP site entry and the ETRs have not registered = (yet). >>>>=20 >>>>> 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. >>>>>=20 >>>>> It seems like a poor design to return no response. Is there not = some >>>> A response is ALWAYs returned in LISP-DDT. The only time it can=E2=80= =99t is when a Map-Request cannot get to where its going or the = Map-Referral cannot get back to the DDT-client source. And that is the = only case we call a =E2=80=9Ctimeout=E2=80=9D. >>>>=20 >>>>> sort of "server failure" response that can be returned to the DDT >>>>> client? >>>>>=20 >>>>> 8. Pseudo Code and Decision Tree diagrams >>>>>=20 >>>>> 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. >>>> Agree. We should have new text to make this more clear. >>>>=20 >>>>> 9. Example topology and request/referral following >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Are lines in the diagram intended to cross? If so, they could be >>>>> clarified as: >>>> Yes, because each parent points to 2 children. >>>>=20 >>>>> +---------------------+ +---------------------+ >>>>> | 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| >>>>> +---------------------------+ = +---------------------------+ >>>>>=20 >>>>>=20 >>>>> 10. Securing the database and message exchanges >>>>>=20 >>>>> 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. >>>>>=20 >>>>> s/the XEID-prefix/an XEID-prefix/ >>>> Agree. >>>>=20 >>>>> But the first sentence doesn't say the same thing as the second >>>>> sentence. Better would be >>>>>=20 >>>>> 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. >>>> Agree. >>>>=20 >>>>> 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. >>>> Really good point. I definitely agree. >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>> It should yes. >>>>=20 >>>>> 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. >>>> An RLOC record contains LCAF type 11 with the RLOC/address of the = referral and key material. >>>>=20 >>>>> 11. Open Issues and Considerations >>>>>=20 >>>>> o Management of the DDT Map Resolver referral cache, in = particular, >>>>> detecting and removing outdated entries. >>>>>=20 >>>>> 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. >>>> Agree. >>>>=20 >>>>> 13. Security Considerations >>>>>=20 >>>>> 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. >>>>>=20 >>>>> This sentence is obscure, because "DDT security" is not defined >>>>> anywhere, and there seems to be no optional security mechanism >>>>> described in the draft. >>>> We have referred to LISP-DDT-SEC to mean the public/private key = signing of Map-Referral messages. That is what the reference to DDT = security could mean. But this section could be confidentiality support = as well. >>>>=20 >>>>> 14.2. Informative References >>>>>=20 >>>>> [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. >>>>>=20 >>>>> 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). >>>> Should be normative since we are about to publish the LCAF RFC. >>>>=20 >>>>> [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, >>>>> >>>> abs_all.jsp?arnumber=3D5586446>. >>>>>=20 >>>>> This reference is not referenced. >>>>>=20 >>>>> [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, . >>>>>=20 >>>>> 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. >>>> Agree. >>>>=20 >>>>> Dale >>>> Thanks again for the really detailed comments. >>>>=20 >>>> Dino >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> lisp mailing list >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Fri Nov 4 11:23:44 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2414B1295ED; Fri, 4 Nov 2016 11:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC9KSsBpHXHF; Fri, 4 Nov 2016 11:23:35 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AAA129608; Fri, 4 Nov 2016 11:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4261; q=dns/txt; s=iport; t=1478283814; x=1479493414; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4DL0lb6SzpTw5Oz6GsQdjPNdqYYW5tiU/R17ULFfsFI=; b=Amh1b+SEkeQEttQ37/6/YM3QhGa6phNsG9hXIWYMG36uwOwOH+MZ97n9 rV0VOYMMOb2PF7b8iekoHs66+oW+de//d6F6/ZDjkmc37fRDY9Q4ice6F vE0s5VJwOEq6S2wel5ss0OqfHlGjYfqZMkFL+u8dfVvK9gjct8Tvd4JHe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQDx0BxY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy4BAQEBAXcqUo04lwCSN4IPgggohXsCglYUAQIBAQEBAQEBYii?= =?us-ascii?q?EYgEBBCMVQRALGAICJgICVwYBDAgBAYhUDq8vjHQBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQmFNoF9CIJQhBkRAYMgglwFiEuRWIY0igyBboRvgxiGFY0hhAQeN1k?= =?us-ascii?q?KCYNcgUY9NAGFCQ0XB4IPAQEB?= X-IronPort-AV: E=Sophos;i="5.31,444,1473120000"; d="scan'208";a="649709402" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2016 18:23:31 +0000 Received: from [10.55.206.135] (ams-asmirnov-nitro6.cisco.com [10.55.206.135]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id uA4INVCC003953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Nov 2016 18:23:31 GMT To: Stephen Farrell , The IESG References: <147757226834.24715.16366455756541086706.idtracker@ietfa.amsl.com> <74bb00ca-b694-95ea-48a8-4241e3eb7e38@cisco.com> <14cddbee-ebf4-6eeb-e772-4ef6f550f28b@cs.tcd.ie> <29496480-ebe1-2c3d-4ba5-2f814774f5f1@cisco.com> <70451832-0828-3108-9f9c-1c706eb1322d@cs.tcd.ie> From: Anton Smirnov Organization: Cisco Systems Message-ID: <014ec345-dcea-5a0f-8272-ebab9da3375d@cisco.com> Date: Fri, 4 Nov 2016 19:23:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <70451832-0828-3108-9f9c-1c706eb1322d@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: asmirnov Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-ddt@ietf.org, lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 18:23:37 -0000 Hi Stephen, OK, we will do it like this in the next revision of text. Anton On Friday 04 November 2016 17:27, Stephen Farrell wrote: > Hiya, > > On 04/11/16 16:12, Anton Smirnov wrote: >> Hi Stephen, >> >> will it be OK if we mark in the document security algorithm 1 as >> reserved without even elaborating that it is/was RSA-SHA1 and the only >> security algorithm specified in the RFC will be 2 == RSA-SHA256 ? >> >> This will ensure that whoever is using algorithm 1 will not run into >> compatibility issues but RSA-SHA1 will be clearly non-RFC-compliant. > How about defining alg=1 as rsa-sha1 and marking that as > deprecated with alg=2 as rsa-sha256 as the MUST implement? > (I don't care myself if you have an IANA registry for those > yet or not, doing it in text is fine.) > > S > >> Anton >> >> On Tuesday 01 November 2016 22:09, Stephen Farrell wrote: >>> Hiya, >>> >>> On 01/11/16 18:51, Anton Smirnov wrote: >>>> Hello Stephen, >>>> >>>> thanks for your comment. >>>> >>>> Existing DDT implementations are already using RSA-SHA1, so we cannot >>>> simply replace it with RSA-SHA256. But we should be able to add the >>>> latter as another signing algorithm. >>> Really? The sha-1 weaknesses for use in signatures were >>> found and documented in an RFC in 2005. [1] We published >>> an RFC attempting to tidy up remaining loose ends related >>> to sha1 for signatures in 2011. [2] Asking for rsa-sha1 now >>> is really very far behind the state of the art. >>> >>> But are you talking implementations or deployments here? >>> If mostly the former then I think you ought remove rsa-sha1 >>> entirely and replace with rsa-sha256. That is a trivial >>> code change and I can see no justification for not making >>> that change. >>> >>> If you are talking about existing deployments please >>> provide the argument as to why those are such that we >>> should publish an RFC that calls for use of an obsolete >>> signature algorithm 11 years after the initial crypto >>> weaknesses were documented in the IETF. If there are good >>> arguments for that a) I'll be surprised, and b) my plan >>> would be to ask for advice from the security area - I >>> don't think we've hit this case before where an experimental >>> RFC wants to use such a thoroughly obsolete signature >>> algorithm, one that would never be ok in a standards >>> track RFC and one where it's really easy to do the right >>> thing instead. >>> >>> Cheers, >>> S. >>> >>> [1] https://tools.ietf.org/html/rfc4270 >>> [2] https://tools.ietf.org/html/rfc6194 >>> >>> >>>> Authors will take in your comments in the next revision of the >>>> draft. >>>> >>>> Anton >>>> >>>> On Thursday 27 October 2016 14:44, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-lisp-ddt-08: 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-ddt/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> 6.4.1: RSA-SHA1 is not the right choice today, shouldn't >>>>> this be RSA-SHA256? >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> - 6.4.1: Can you clarify what bits are signed? I'm not >>>>> quite sure from the description given - you can have >>>>> more than one signature but you say the the "entire >>>>> record" is covered. >>>>> >>>>> - Section 8: Where's signature validation in the >>>>> pseudo-code? >>>>> >>>>> From nobody Mon Nov 7 16:35:39 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287D4129538; Mon, 7 Nov 2016 16:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQR0yHcndDD5; Mon, 7 Nov 2016 16:35:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561D0129522; Mon, 7 Nov 2016 16:35:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1E86BE38; Tue, 8 Nov 2016 00:35:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7p_04ofWmfo; Tue, 8 Nov 2016 00:35:25 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE9B7BE32; Tue, 8 Nov 2016 00:35:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478565325; bh=p6Yqi7v6cJt7IdPE48uCyu+GJftWKMauPrulBfWebTo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GVldwi21A5cJ6XUB7cLHlrhFLismWBLaQxKBpCF0dha8wqd7WM41j/+Knk4vojoDS EyPfjshalWnA7p8y/oi1iYke25NrCM0mRoaErb9EXp8FjUOirG57xT9O581VNajezV tIYgcDzDTiOX6lTj20uXuQZfNbQmVDNOoKNUtqow= To: Dino Farinacci References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 8 Nov 2016 00:35:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050707060208090100080903" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, The IESG , lisp@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 00:35:32 -0000 This is a cryptographically signed message in MIME format. --------------ms050707060208090100080903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dino, Apologies for the slow response... I checked the diff from -17 to -20 before replying. On 14/10/16 14:21, Dino Farinacci wrote: >> I basically support Alexey's discuss position and Ben's comment but >> with a bit more detail below. >=20 > Thanks for your comments Stephen. >=20 >> - section 3: I don't see how you can produce a canonical order of >> the LCAF encodings if two can contain e.g. the same values other >> than different URLs, since there is no canonical way to order URLs >> (or JSON structures etc.) without a lot more specification. >=20 > We want to define an order so if an implementation parses, say Type > 4, it can optimize to know that Types 1-3 will not come after Type 4. > We can achieve that with this text: >=20 > [RFC6830] states RLOC records are sorted when encoded in control=20 > messages so the locator-set has consistent order across all xTRs for=20 > a given EID. The sort order is based on sort-key {afi, RLOC-=20 > address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF-=20 > Type}. Therefore, when a locator-set has a mix of AFI records and=20 > LCAF records, they are ordered from smallest to largest AFI value. Sorry I'm not getting that. When I read "canonical" I take that to mean that anyone given the items in any order can re-construct the same set of octets. Are you defining some other format that doesn't amount what I perceive as being a canonical form? (For background, most canonicalisation that turns up in security relates to signature/MAC inputs where you need to produce the exact same set of bits.) If you don't need what I'd call a canonical form then maybe calling it something else might be good, or explaining that you're using that term differently from the normal crypto usage. If you do need (what I'd call) a canonical form, then I think more work is still needed. (And that's tricky for URIs as there is no general canonicalisation for those.) >=20 >> - 4.3: I agree with Ben's comment. You ought include some >> text here to the effect that this information can be privacy >> senseitive and to recommend not sending or storing it in such >> cases. >=20 > I did that for the next revision. I don't see the recommendation to not use/send/store this unless needed nor anything other than a generic warning to go read BCP160, which I'm not at all sure is something that would help LISP implementers. Do you really think they'll buy into the geopriv architecture? I don't really. I'd argue that it'd be better to explain the issues here and to recommend to avoid the pitfalls we know exist. >=20 >> - 4.4: there are also potential privacy issues here if this could >> be used to identify traffic that is from one specific host behind a >> NAT. A similar privacy warning should be included. >=20 > It does not identify any host. Are there no LISP use-cases where the Private ETR RLOC Address or RTR RLOC Address could map to a host behind a NAT e.g. in my home? If there are (and there seem to be many LISP use-cases:-) then maybe this warning is needed. But if not, yes, it'd not be needed. Can you clarify? >=20 >> - 4.7: Sorry, when is key material sent in a message? How is that >> protected? (Key ids are fine, but not key values) >=20 > That is documented in the two use-case references. So for DDT, those are always public keys, right? And are part of some PKI or equivalent. If so, those are fine. But for lisp-crypto, if this can be a long term symmetric key, or a derived shared secret then more needs to be said I think. Or at least, we need the argument that storing such keys is safe. Can you provide that? I don't recall seeing that go by in the discussion of lisp-crypto but I may be forgetting. >=20 >> - 4.10.2: The same privacy issues apply here as for 4.3 and 4.4, if >> the MAC address maps to e.g. a portable device carried by a >> person. >=20 > In this case, the MAC address can be a host/person. I put a refernece > to the Security Considersations section that references > RFC6280/BCP160. See above WRT BCP160. I'm really not sure it's a great reference here, in terms of being useful to implementers. >=20 >> - 4.10.3 and all of section 5: What are these for? I don't see the >> sense in defining these if there is no well defined way to use >> them. Any of these might have undesirable security and/or privacy >> characteristics. >=20 > We have use-cases for them. And they are being documented in both > other working group and individual contributed drafts. Yeah but this seems like throwing the kitchen-sink and all at the mapping system, which seems to me to be a recipe for security and privacy failures. With the level of detail now available, how could we know for sure if I'm right or not? Wouldn't it be better to define these as they are needed and as they are better understood from the security/privacy POV? Cheers, S. >=20 >> - Section 6: There are security considerations. See above. >=20 > I added text per Ben=E2=80=99s comments. >=20 > Thanks, Dino >=20 --------------ms050707060208090100080903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDgw MDM1MjVaMC8GCSqGSIb3DQEJBDEiBCAPu4L2VUgvq5k72y4Q5XbcNYf3YvzHvPeYrbzyvVxc aDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBLQITyhR5LCSDR8WP90HotX7d/UR59S2GIVIR1WweSckBNRLKPFg5q +M5asxBpjIaTM5ljbrPd0nFirdWRqNpfOCiymUMmwa4CIGvh+HOjz9ADfahMUs0DA7mZeC3X hEGwVLCGWTER7JuL879wKVC1LNKy9alsrw7rHf8TQCL5q+J34YhCk6dljqffQCX4rZls4xuz KEhh5CAv4uyYbP5VEF4Ng/mS9vru1ovMbhVXfUUC67bCaFijnMzi9q6EkunVhCVLuhH3SyB6 RnLEqMiPwVuh0OjMREBAggDFEesZMtrJONoXPD5Bmp/PaKZKGqxuZ8mCtBwDmDlAU9K29Zuh AAAAAAAA --------------ms050707060208090100080903-- From nobody Mon Nov 7 19:03:26 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFFC129522; Mon, 7 Nov 2016 19:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E90IdHquwQpM; Mon, 7 Nov 2016 19:03:19 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A3712948F; Mon, 7 Nov 2016 19:03:19 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id c47so99860150qtc.2; Mon, 07 Nov 2016 19:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=xwLH31T6chOl2T8tHrG69GDhE+mW7DnPjZimytY3NX0=; b=qadxJrNtZ+ShGP1NAdUYuSFEl4tOYckRj2UWorn58gJK2yHtEEG4icRs2U4e01n2+V byaTFNORRXP8QCb+mxruzu4Mg49yEB7BGkd0nZcWXfbnR0ucB9Utc9ehuWFeUs9kBw7r eietOZaDl7hjq40hIbpfCcaM3lHc7dmGiBgMgLDEmCXd/RT9Mun7YTDMaI1Hh+WVTqwM mjWTLMMWcUEo9YDvhzPKKIAuCPjav/tZq+L1unz/6X5/PoORJQR6wOf1jIwY4FwL+Buq xOqOhLTzllwcC1dunT3tW8Q/duplmDj0F9caRcfyylHux8DS+XMxI3bZ3mfbDeAyffnW AUcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=xwLH31T6chOl2T8tHrG69GDhE+mW7DnPjZimytY3NX0=; b=BLMUu8ABzjB03jxM2CbmNdBpUMXCj6BIwn+mvUa1IQVL12285HmSrIn+cqamEbSx53 b4GxALRp88cS8OVR6ZgPfnpNCctSOM71Z742xLoIL/Ae63JUEAdh0MbV5+Z92yDMjI7B lx9ovi88MjEatG0HftKWozEYYd3P+KXtMwHfkoIdHU0rsop3N2x5cL2WUvL4l1Kbe2rS Kkg2YcRIUvJgxc/hkrUzAk82NJZGu3gy7OvHjHz1fmDfGkdbQn402OV4mmEhhFGZjfTM a7ZivyOoocN+nGbajE0glrPtZh9QPfedNBihTud4eG9jLhJBeRG1bg+kuZ+5yxDI5dtf Jrbw== X-Gm-Message-State: ABUngvf0S9vL7k4qibHMnCbPfub8nFUr0znNojPRuM3pMy6iLcM3F6Siz82jWy5EEBdyAqPP1sgX1zrgj1K96w== X-Received: by 10.200.51.251 with SMTP id d56mr10459260qtb.89.1478574198658; Mon, 07 Nov 2016 19:03:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.38.34 with HTTP; Mon, 7 Nov 2016 19:03:18 -0800 (PST) From: Padma Pillay-Esnault Date: Mon, 7 Nov 2016 19:03:18 -0800 Message-ID: To: ideas@ietf.org, LISP mailing list list Content-Type: multipart/alternative; boundary=001a1134f2ece299d60540c16100 Archived-At: Subject: [lisp] IETF97 IDEAS Kickoff Meeting Agenda X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 03:03:21 -0000 --001a1134f2ece299d60540c16100 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Everyone, The kickoff meeting for the IDEAS (ID EnAbled networkS) list will be held during IETF97. 1. Meeting Information Date: Thursday, 17th November 2016 Time : 6:00 - 7:30pm Venue: Studio2 Mailing list: IDEAS List address: ideas@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dideas To subscribe: https://www.ietf.org/mailman/listinfo/ideas Related areas: RTG, OPS 2. Agenda Padma Pillay-Esnault (Huawei) - Introduction on problem statement for IDEAS (10 mins) Tom Herbert ( Facebook) - The ILA protocol and NMS (10 mins) Dino Farinacci ( Lispers) - LISP Mapping system, How it works? (10 mins) Gerry Forster ( UoSurrey) - ETSi NGP: GTP, Mobility & Flat 5G Architecture( 15 mins) Fabio Maino(Cisco) - Deployment experience of Mapping Systems ( 10 mins) Dave Meyer (UoOregon/Brocade) - Machine Learning and Network Mapping System ( 15 Mins) A. Cabellos, J Vilanova & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco) = =E2=80=93 A Blockchain-based Mapping System (15 mins) 3. Related Documents and Reads: https://tools.ietf.org/html/draft-padma-ideas-problem-statement-00 https://tools.ietf.org/html/draft-herbert-nvo3-ila-03 https://tools.ietf.org/html/rfc6830 https://tools.ietf.org/html/rfc6833 http://www.3gpp.org/release-14 Please feel free to forward. Looking forward to seeing you all in Seoul. Padma --001a1134f2ece299d60540c16100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,

The kickoff meeting= for the IDEAS (ID EnAbled networkS) list will be held during IETF97.
=

1. Meeting Information=C2=A0

D= ate: Thursday, 17th November 2016
Time : 6:00 - 7:30pm
= Venue: Studio2

Mailing list: IDEAS

Related areas:= RTG, OPS


2. Agenda=C2=A0
=

Padma Pillay-Esnault (Huawei) - Introduction on problem stat= ement for IDEAS (10 mins)

Tom Herbert ( Facebook) - The ILA protoco= l and NMS (10 mins)

Dino Farinacci ( Lispers) - LISP Mapping system= , How it works? (10 mins)

Gerry Forster ( UoSurrey) - ETSi NGP= : GTP, Mobility =C2=A0& Flat 5G Architecture( 15 mins)

Fab= io Maino(Cisco) - Deployment experience of =C2=A0Mapping Systems ( 10 mins)=

Dave Meyer (UoOregon/Brocade) - Machine Learning =C2=A0and Network= Mapping System =C2=A0( 15 Mins)

A. Cabellos, J Vilanova= & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco)=C2=A0=E2=80=93 A Blo= ckchain-based Mapping System (15 mins) =C2=A0


=
3. Related Documents and Reads:



Please feel free to forward.
=
Looking forward to seeing you all in Seoul.=C2=A0
<= div>
Padma
--001a1134f2ece299d60540c16100-- From nobody Tue Nov 8 08:42:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7988512957F; Tue, 8 Nov 2016 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYLuQlKNIH69; Tue, 8 Nov 2016 08:42:04 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A66A12711D; Tue, 8 Nov 2016 08:42:04 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id i88so109915567pfk.2; Tue, 08 Nov 2016 08:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B6xxnkYodVrfbQJkPVGWM8vlMVmvMgPZ8kYl7flAoq4=; b=nh+0pMvtThleTbNO0VWkO7kgUh/dWWaSDCCgcuJa/6xOEqNH+363t0TBSzGghzlHaA wbDCyygRWqaxDp/vZTPE0EmsFhMH/MLxwGVB1rBpu6jDF6sAuuORdcM+ryoIj78AotmL HnndVvcQJlybrxCLlzRB4PHSAQqgAPdciA+xoik344w8WP/G+hqspCFdpJlWx7X4rQG5 1wSSmK1W/SFgMYVeEHE7yaoek5NGN1EemMAlyoTYnN2VxDxZJIXid9IuOJab5huPQRMa +RZv5/HarChDpYLYOfQekzXGW4LXxxYZJPQKH13NKFubxTWKIVCyZfuDZl97xeIKATws C13g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=B6xxnkYodVrfbQJkPVGWM8vlMVmvMgPZ8kYl7flAoq4=; b=E7p6ADkNTxRKrz1K7F02Aw7B6dK4JDeAJTBf6hOQV7FxGT4yRLAQHTTcZK2CJPuFqX FIDwFNuay0l+44afh9l9EdN2vtXZwo8Ju7uZe6ZUvWC6htcFHsL+npig2Er759L1LcXg Lu0SBnVPVY2ubUorHRzsqbL8r0Qj/ZNT7fwKNhceRDtXA56Ot/Kl7+mVkmYcdj5jDASb 4hLZqZMFO9TcIOwj1NKeOAwuwRkbWEfEWer9QKswnCxwKT5ne+HOuJVXjB1kc88GHIE7 e4Z8lFu63jl6HEp/kODzfw5DSbymxMvKZKzFCOjEFY5GlNF2MO5BJ7coGV9yqbKySXV2 aJog== X-Gm-Message-State: ABUngvdRfFSyth5wKTNQXZ1MDR7QniKsHoSGaBC59j6/9TvFe/xnHIWs4vYwhdJPgOmUaw== X-Received: by 10.98.7.151 with SMTP id 23mr24821080pfh.5.1478623323724; Tue, 08 Nov 2016 08:42:03 -0800 (PST) Received: from [172.20.10.2] (mobile-166-171-248-049.mycingular.net. [166.171.248.49]) by smtp.gmail.com with ESMTPSA id yc7sm49523909pab.24.2016.11.08.08.42.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 08:42:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: Date: Tue, 8 Nov 2016 08:42:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list , The IESG , draft-ietf-lisp-lcaf@ietf.org Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:42:05 -0000 > Hi Dino, >=20 > Apologies for the slow response... >=20 > I checked the diff from -17 to -20 before replying. Great, thanks. Please ack based on if you agree with my responses below. = I didn=E2=80=99t see anything you said where I need another update. But = want your agreement first. >> [RFC6830] states RLOC records are sorted when encoded in control=20 >> messages so the locator-set has consistent order across all xTRs for=20= >> a given EID. The sort order is based on sort-key {afi, RLOC-=20 >> address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF-=20= >> Type}. Therefore, when a locator-set has a mix of AFI records and=20 >> LCAF records, they are ordered from smallest to largest AFI value. >=20 > Sorry I'm not getting that. When I read "canonical" I take > that to mean that anyone given the items in any order can > re-construct the same set of octets. Are you defining some > other format that doesn't amount what I perceive as being a > canonical form? (For background, most canonicalisation that > turns up in security relates to signature/MAC inputs where > you need to produce the exact same set of bits.) The ordering is for the sole purpose of using reachability bits that are = consistent among multiple ETRs that are registering the same RLOC set. = Here is an example. Say we have two ETRs for a LISP site, their RLOCs = are ETR1 and ETR2 and they are both registering an EID-prefix, we want = the mapping to be: EID-prefix -> {ETR1, ETR2} And we want ETR1 to register the above mapping in the same order as = ETR2. So we when the RLOC reachability bits are set for this RLOC-set = (say 0x3), we know the low-order bit means we are advertisting the = reachability-bit for ETR1, and the 0x2 bit is for ETR2. That is why we have a sort order. This is discussed in detail in = RFC6830, and we are just waying here that if the RLOCs are accompanying = with other data, that is defined by a specific LCAF encoding that the = RLOC address are sorted. > If you don't need what I'd call a canonical form then maybe > calling it something else might be good, or explaining that > you're using that term differently from the normal crypto > usage. We are using it from an =E2=80=9Caddress=E2=80=9D perspective. Has = nothing to do with security. ;-) > If you do need (what I'd call) a canonical form, then I think > more work is still needed. (And that's tricky for URIs as > there is no general canonicalisation for those.) It is a canonical form for all new types of addresses or information we = want to add in the future. >=20 >>=20 >>> - 4.3: I agree with Ben's comment. You ought include some >>> text here to the effect that this information can be privacy >>> senseitive and to recommend not sending or storing it in such >>> cases. >>=20 >> I did that for the next revision. >=20 > I don't see the recommendation to not use/send/store this > unless needed nor anything other than a generic warning to > go read BCP160, which I'm not at all sure is something that > would help LISP implementers. Do you really think they'll > buy into the geopriv architecture? I don't really. >=20 > I'd argue that it'd be better to explain the issues here > and to recommend to avoid the pitfalls we know exist. It is here (page 35-36 in -20): 6. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratuitously. It is recommended that any documents that specify the use of the Geo-Coordinates LCAF Type should consider the applicability of the BCP160 [RFC6280] for location-based privacy protection. >=20 >>> - 4.4: there are also potential privacy issues here if this could >>> be used to identify traffic that is from one specific host behind a >>> NAT. A similar privacy warning should be included. >>=20 >> It does not identify any host. >=20 > Are there no LISP use-cases where the Private ETR RLOC Address or > RTR RLOC Address could map to a host behind a NAT e.g. in my home? Yes, kinda. But there is no need for the private-RLOC right now and we = are working that out in the NAT-traversal individual submission draft. > If there are (and there seem to be many LISP use-cases:-) then > maybe this warning is needed. But if not, yes, it'd not be needed. > Can you clarify? We don=E2=80=99t know how ot clarify yet. We can in the future. >=20 >>> - 4.7: Sorry, when is key material sent in a message? How is that >>> protected? (Key ids are fine, but not key values) >>=20 >> That is documented in the two use-case references. >=20 > So for DDT, those are always public keys, right? And are > part of some PKI or equivalent. If so, those are fine. They are public keys and DDT, itself can be regarded as a PKI. But each = parent transmit the public-key of the children it is referring. So = it=E2=80=99s not a table lookup mechanism but an on-demand push. > But for lisp-crypto, if this can be a long term symmetric > key, or a derived shared secret then more needs to be said LISP-DDT-SEC is control-plane security, and lisp-crypto is data-plane = security. They are not related and don=E2=80=99t depend on each = other=E2=80=99s functionality. > I think. Or at least, we need the argument that storing > such keys is safe. Can you provide that? I don't recall We don=E2=80=99t store keys for lisp-crypto. We store public-keys for = LISP-DDT. > seeing that go by in the discussion of lisp-crypto but I > may be forgetting. So are you good with my response? >=20 >>=20 >>> - 4.10.2: The same privacy issues apply here as for 4.3 and 4.4, if >>> the MAC address maps to e.g. a portable device carried by a >>> person. >>=20 >> In this case, the MAC address can be a host/person. I put a refernece >> to the Security Considersations section that references >> RFC6280/BCP160. >=20 > See above WRT BCP160. I'm really not sure it's a great > reference here, in terms of being useful to implementers. See Security Considerations section. >=20 >>> - 4.10.3 and all of section 5: What are these for? I don't see the >>> sense in defining these if there is no well defined way to use >>> them. Any of these might have undesirable security and/or privacy >>> characteristics. >>=20 >> We have use-cases for them. And they are being documented in both >> other working group and individual contributed drafts. >=20 > Yeah but this seems like throwing the kitchen-sink and all > at the mapping system, which seems to me to be a recipe for > security and privacy failures. With the level of detail now > available, how could we know for sure if I'm right or not? > Wouldn't it be better to define these as they are needed > and as they are better understood from the security/privacy > POV? They are needed and we are experimenting with them now. We can apply = updates when we learn more. We still do rough concensus and running = code. ;-) Dino From nobody Sun Nov 13 18:48:50 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87111296CB for ; Sun, 13 Nov 2016 18:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVip2SzCVYOD for ; Sun, 13 Nov 2016 18:48:32 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06991296B6 for ; Sun, 13 Nov 2016 18:48:32 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id p66so48131872pga.2 for ; Sun, 13 Nov 2016 18:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=ICbW5gNmh4MSRTUu214c16hsbl/u+SBjfTKRErHuE/I=; b=mSFg2N/Q2jGMOzwwj5oFsL6hcSTgjPOb9t+DAT1/uxwKDl4Ub4kOggvILjHaFau0M3 KZztnjIQ3iCu41b8fXlGpX8VREaZ1hulZbf/oB2m+kMznyIFVJvDbbH1YaO41mjYtJKW P/DtDGBW93s0EAohJipGSunsasTNn+i/cVWdbvwUfcxvoHmjH9NGAK7DqU52w7hRa1aa 6Gm6LgKKti7Zo8QhD8kznqsZQOzqxA/MQ3pspT6640OkcfBzAjJeOfhlAVkU+MUl1Jmf mvH3z49VXRn5yE+kUmlOCVMQQgRRLmFw1qvE8UcfR7fYx2GZjEFTh7mby3idlZyg9Jjp eO8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=ICbW5gNmh4MSRTUu214c16hsbl/u+SBjfTKRErHuE/I=; b=dBmmJ+eVNwzDe7ICr2XYwUsf5d7Mo5Z7YWcbheKnXydqFFKXtWEP2q1cYOjXntvd2i JEqcPqCSTPTQr6EUiN0u2IiWCmVSAmc78oY9ZXCC0tn8gj7hWYtSwzp9axULK4mojcpt HEDuLmJhfRnobptTadW1s6YXJXshcJ5b8Vt/2Gyjxiqlij5YQVdl46SPv325zlmcKL8d qWmcDyXDAEQ/ZGINZfpNMuSuVagOlFuQ4KQFo8FxwmxonKOO2o921KlX8Fjl0o8jE2fQ cFtmyWev33TMissVdvF72YdnQCL/ljXXos1q755aqA7Kkcr0DASBXdZfA7rrZgii9QA4 6N1w== X-Gm-Message-State: ABUngvetJ2BhQmQEUDQU20sfvhoYXCErFWe2OnyIIGmCBbYKvHfVT0xZT4KMrTX7CGrM/Q== X-Received: by 10.99.129.200 with SMTP id t191mr24580880pgd.180.1479091712352; Sun, 13 Nov 2016 18:48:32 -0800 (PST) Received: from t2001067c03700128449a06d86e985396.v6.meeting.ietf.org ([2001:67c:370:128:449a:6d8:6e98:5396]) by smtp.gmail.com with ESMTPSA id q9sm30779180pfg.47.2016.11.13.18.48.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2016 18:48:31 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_A1F3DBE9-989C-4710-B323-72646106E424" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Mon, 14 Nov 2016 03:48:25 +0100 To: LISP mailing list list X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org Subject: [lisp] Slides for Wednesday's meeting X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 02:48:49 -0000 --Apple-Mail=_A1F3DBE9-989C-4710-B323-72646106E424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To all presenters of the meeting, Please send your slides to the chairs > by Tuesday (tomorrow) noon at latest. So that we have time to upload everything on the material page.=20 Thanks ciao L.= --Apple-Mail=_A1F3DBE9-989C-4710-B323-72646106E424 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
To all presenters of the meeting,

Please send your slides to the chairs <lisp-chairs@ietf.org> by Tuesday (tomorrow) noon at latest.
So that we have time to upload everything on the material page. 

Thanks

ciao

L.
--Apple-Mail=_A1F3DBE9-989C-4710-B323-72646106E424-- From nobody Mon Nov 14 00:20:00 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4011296D3 for ; Mon, 14 Nov 2016 00:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCN9fVtVpERD for ; Mon, 14 Nov 2016 00:19:56 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2791C1296C0 for ; Mon, 14 Nov 2016 00:19:55 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id uAE8JqZC025006 for ; Mon, 14 Nov 2016 09:19:52 +0100 From: "Jose Saldana" To: References: <147911121305.961.18254720968087897918.idtracker@ietfa.amsl.com> In-Reply-To: <147911121305.961.18254720968087897918.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2016 09:19:55 +0100 Message-ID: <007301d23e4f$e18bcde0$a4a369a0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLwcwwqU0N1Xwbo/0CwIZ2zM25S6p6buXDw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: Subject: [lisp] RV: New Version Notification for draft-saldana-lisp-compress-mux-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 08:19:59 -0000 FYI. Greetings from Europe, Jose > -----Mensaje original----- > De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Enviado el: lunes, 14 de noviembre de 2016 9:14 > Para: Jose Ruiz Mas ; Jose Saldana = ; > Julian Navajas ; Jose Mas ; Julian > Fernandez Navajas > Asunto: New Version Notification for = draft-saldana-lisp-compress-mux-01.txt >=20 >=20 > A new version of I-D, draft-saldana-lisp-compress-mux-01.txt > has been successfully submitted by Jose Saldana and posted to the IETF > repository. >=20 > Name: draft-saldana-lisp-compress-mux > Revision: 01 > Title: Header compression and multiplexing in LISP > Document date: 2016-11-14 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-saldana-lisp-compress-mux- > 01.txt > Status: = https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/ > Htmlized: = https://tools.ietf.org/html/draft-saldana-lisp-compress-mux-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-saldana-lisp-compress-mux-01 >=20 > Abstract: > When small payloads are transmitted through a packet-switched > network, the resulting overhead may result significant. This is > stressed in the case of LISP, where a number of headers have to be > added to each packet. >=20 > This document proposes to send together, into a single packet, a > number of small packets, which are in the buffer of a ITR, having = the > same ETR as destination. This way, they will share a single LISP > header, and therefore bandwidth savings can be obtained, and a > reduction in the overall number of packets sent to the network can = be > achieved. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until > the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Mon Nov 14 16:42:11 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA1C12960A for ; Mon, 14 Nov 2016 16:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCeM5yQJWGpJ for ; Mon, 14 Nov 2016 16:42:08 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C7712957F for ; Mon, 14 Nov 2016 16:42:08 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id t79so133504138wmt.0 for ; Mon, 14 Nov 2016 16:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=OrEnCJBN6GgxUvKJhoNuyPYArRvh/9CIDydtuT++A1Q=; b=Cf4Gp2IBXIYyJMnyEsQk3M7+VGHcY4USmfdJ6TkoyrFzmw6p39/vC79cpICAt6Ppfe vpkBEPfzKIESRBzJXKP6zVg9nQNVmoK4mh7o+3r7W5/68z/y3OZM7Dsm9hCa0psbmAxe fy+LnKqHZa3j7FxA/HooTtL8FUvcbxm1xURSqDp1pvfjfQ3SRYRGmzO3kokUxEfZ2jgv I1h0o4XdVYliLWNreOxJVHIyhnA1DEXEqtUmk4exlnxnv1yhrTgKPGi8cnNeNeSxwSXI xNq5NUmRzzU8J1psggJFm9KhlgR8Odau3thoPs1Cb37rAH3fnIWzJ2rLvx4gTlpoMf9h EGJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OrEnCJBN6GgxUvKJhoNuyPYArRvh/9CIDydtuT++A1Q=; b=mcYICr3XTcDqtDy69Xuh30n1EJEOEMIvDwTw9lFEvoFk5JbxzMBZfRVqZmb38TGEwF f0pBh7tfvOoDlosYe2CqrL1IdW7+qYsFkGqTFHMt8K10KP4M/twxn5YFs8t8pAdpSSon 4QfLC6RVQUvjVYHEJNLueUkmmg/l4zxVAU5RneVEJUb1db1fFTnh9UyPgusg8QRaIkl8 M0eIMUJgsaV0rGtJe5QEBqNXP+SW6IZMW8p/QMHvc+H4Bm2NI6w5cPLJa5pOqtHzM8VJ 1AoFmeFBsWI9+elBRwXP5aQIpSpc1DLGg6RFUXAM95bNiN8SCkBBexQ/1A/vUUFfAWlu RBOA== X-Gm-Message-State: ABUngvezOxaFgmmFuHI3v3C7CCBbDJgQVFQ3AqGuVBKv0NqYYSQVwJ1A5QtZQkpV9ivPuk/ugEffhTG/CNHfYw== X-Received: by 10.25.139.195 with SMTP id n186mr9290734lfd.27.1479170526978; Mon, 14 Nov 2016 16:42:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.8.202 with HTTP; Mon, 14 Nov 2016 16:42:06 -0800 (PST) From: Albert Cabellos Date: Tue, 15 Nov 2016 01:42:06 +0100 Message-ID: To: "lisp@ietf.org" Content-Type: multipart/alternative; boundary=001a113ebaa6d2aa4b05414c390e Archived-At: Subject: [lisp] 6830bis & 6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 00:42:11 -0000 --001a113ebaa6d2aa4b05414c390e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all We have submitted our take on 6830bis and 6833bis, we=C2=B4ll present them during the LISP WG meeting: https://tools.ietf.org/html/draft-farinacci-lisp-rfc6830bis-00 https://tools.ietf.org/html/draft-farinacci-lisp-rfc6833bis-00 You can find the diff from RFC6830 and RFC6833 respectively here: https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-farinacci-l= isp-rfc6830bis-00.txt https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-farinacci-l= isp-rfc6833bis-00.txt Thanks Albert --001a113ebaa6d2aa4b05414c390e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all

We have submitted our take on 68= 30bis and 6833bis, we=C2=B4ll present them during the LISP WG meeting:



You can find the d= iff from RFC6830 and RFC6833 respectively here:


=
https://tools.ietf.org/rfcdiff?d= ifftype=3D--hwdiff&url2=3Ddraft-farinacci-lisp-rfc6833bis-00.txt

Thanks

Albert<= /div>
--001a113ebaa6d2aa4b05414c390e-- From nobody Tue Nov 15 17:08:03 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C861294B5 for ; Tue, 15 Nov 2016 17:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtutfWRnmBzx for ; Tue, 15 Nov 2016 17:08:02 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877211293D8 for ; Tue, 15 Nov 2016 17:00:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 702EA240C78 for ; Tue, 15 Nov 2016 17:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479258032; bh=BxklIWs4b2tAF1sWjPaKfIdiGGKdD3EAMyBeic559tI=; h=To:From:Subject:Date:From; b=KoeVaGYLPgdw7VPcJLZNOqcfBhKeT0Bz6/s23O6YZYdfADAc2e7xvgoMcmXdoQNt4 /vaL42suuGLuFzsLNsYgKlER7iUQnfYanjjv95qINmng69VUMJhFd/zK/tgngBu4b8 mqDawhhDqhncJ2uosDuiLU9HxcRrCYVtHGKPD62Q= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-893a.meeting.ietf.org (unknown [31.133.138.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EF18A2403A3 for ; Tue, 15 Nov 2016 17:00:31 -0800 (PST) To: "lisp@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 15 Nov 2016 20:00:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Thoughts on 6830bis and 6833 bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:08:03 -0000 Could the introduction of these documents reference and rely on the LISP introduction document? In the discussion of control being applicable to other encaps, I wonder if there should be a discussion of the assumptions the control plane makes about data plane mechanisms. For example, we assume that there are ways for the data plane to indicate that mapping information is out of date. If the data plane does not do that, then odd control behavior is possilbe and would seem to need to be considered. Thank you, Joel From nobody Tue Nov 15 18:23:52 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85138129458 for ; Tue, 15 Nov 2016 18:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqkUdJUOLUdq for ; Tue, 15 Nov 2016 18:23:49 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1B51295C1 for ; Tue, 15 Nov 2016 18:23:49 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id x23so70573042pgx.1 for ; Tue, 15 Nov 2016 18:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hEu1YJhuYBcUjk5YgcYQOcTB32bsYraydcMWQrLGubc=; b=FH2HE68cVGrzOOswfAGkuiahq//xPzcIe2mgoSR3KBwjBbN7ajOM+mOLYpoBhSOkNY OPoZxoOyQfBqeKYS99bwtp1Joc3pqlWvTxMxKQfDpJFbnMWBg6zrvECTKJhttMSbsViC nRfPj7uVZjPy1nseJigWIFWBTpCyZMhQVeeUtMe3bv88PHpgsUlBWoy+UY15XhJXCjSS r38KCVmKZUrCsyX9ATRBgkUdzLmcKz5qb3RxFa8iUJ3H9yG0AlJxHUj9LvW2aXVgJE8o UzodB2LhUqtIzJ15nnrvP7VZKdzjkGuO1g/vb3zgkPdZ4PB1+AUbbtr0yNe7wsWhweGI XUtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hEu1YJhuYBcUjk5YgcYQOcTB32bsYraydcMWQrLGubc=; b=kKkHH2nFoadpzAO2cBm7q+YebKrLWzO/UBolAhWyDpdUYufv5d3p71UxvcRPvdrCqG KBF6XVvThf/q7xi+ADjqUelPL1qB8lze2kkgTgJAeN+ozdjYOtfLXgb+Z3K4Qy2JHIpM WtWXqYd7ybVcZnElT+KHxYp4ycsHV1CRKw37cHh+xxkNZmi4MPI9Eu7rwcUWExV4hhK5 CcgdFsQQi+clWRk0UzWz7x3wvSYpBxVpeP7BzQbIMp14u8hA4r2NCOjGeGG1FMjiGtPx o503H65quQnhz54FOmVaa+lYDvp0mGOrCgR0RpkafSEkzUv9MEoksKWrgyR5I8RTZKFr klcA== X-Gm-Message-State: ABUngvdEYsRtOQjK00I8sgC4af2XMySoqFH30WiubfHN65CF4toHY4jNn6LPCpw7kU7wjQ== X-Received: by 10.98.31.14 with SMTP id f14mr1123382pff.27.1479263028594; Tue, 15 Nov 2016 18:23:48 -0800 (PST) Received: from t2001067c03700144641913df901fba42.hotel-wired.v6.meeting.ietf.org ([2001:67c:370:144:6419:13df:901f:ba42]) by smtp.gmail.com with ESMTPSA id j68sm47011955pfk.95.2016.11.15.18.23.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 18:23:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: Date: Tue, 15 Nov 2016 18:23:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3C7820B6-CC7B-4A84-A9C2-ECC2B1A30FE6@gmail.com> References: To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "lisp@ietf.org" Subject: Re: [lisp] Thoughts on 6830bis and 6833 bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:23:50 -0000 Yes, good suggestion.=20 We forgot to ask the working group if we should make these working group = documents. Dino > On Nov 15, 2016, at 5:00 PM, Joel M. Halpern = wrote: >=20 > >=20 > Could the introduction of these documents reference and rely on the = LISP introduction document? >=20 > In the discussion of control being applicable to other encaps, I = wonder if there should be a discussion of the assumptions the control = plane makes about data plane mechanisms. For example, we assume that = there are ways for the data plane to indicate that mapping information = is out of date. If the data plane does not do that, then odd control = behavior is possilbe and would seem to need to be considered. >=20 > Thank you, > Joel >=20 > >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Nov 15 18:52:28 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8478F1295E2 for ; Tue, 15 Nov 2016 18:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9guN5dENVWR for ; Tue, 15 Nov 2016 18:52:25 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB765129566 for ; Tue, 15 Nov 2016 18:52:25 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id i88so39588856pfk.2 for ; Tue, 15 Nov 2016 18:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=wexEJm5rNd7mnjXpfipYAToW8T6Lgwvx7EOmb4/cGRA=; b=JxknD7HV0DTyT5kw3htnRJyzddatcKo1tnZH9Xee2VC4EtnN0oL4QXNbb6ExwgjaiC ENR2asCYNAb0LyT1V+/gU67uMGmabZkO/TJlBm09YrgFLDWblQHj9FyrYhJXnTy7QaH4 R/Wk5eRRBBZL/YVs4lqT3T96YQRVOgSYnAmbj/I5pIirxjVojWZsnUFyk0eljqJusql+ 8FM9vy4DszGZmYpeS3PX0yyt/yDmA6kVUVNHzdQu6S+o11JNVoA18YYy+njfpkkbWj7C JUplwJJjgz1Q/sQFMZZ6ib7zuDNWXtZpRd63RKsTEC9QmS45qWtINLTkzkBO3KrI6rY3 wbbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=wexEJm5rNd7mnjXpfipYAToW8T6Lgwvx7EOmb4/cGRA=; b=hHldQqhPZmwgghEoQYiVavdbsKdK+wiqBKCcN4iGC/ePGs7C9w8uq9eCv+bqvZVxKJ q642/0tevUOTxg1yjigug3sJJCDdskhekaIWIFbH29ocegAI+sr/pz8LlclkF5Dum4rq 4I9md+Okoj6pdpznpDRFXtBh9VgsZgBHYVTTS7W1CZG3K86cpcya7fv78Dr5Xl2k5qAR 69kM+bG29VajjUoKYrDvTHVlty+R5aWmNcTuiLjRDHa1WCgmWMR/iyZiqeNpMbz3rZV9 wv1drOsgQ8i0+uCRJY/xgRd70MO+yE/K7Gfc0G/2AoVHSitL8A/dlNF2GNK07bI7Pjvr lVTQ== X-Gm-Message-State: ABUngveHSOZ9GAf6bsJSVSJhJlFWrlqj8zw680xHEDUXsR7pQVqe9jJHWpVfmCeEz3iePw== X-Received: by 10.98.33.133 with SMTP id o5mr1252966pfj.32.1479264745034; Tue, 15 Nov 2016 18:52:25 -0800 (PST) Received: from t2001067c03700128581b8d37f5cd23b9.v6.meeting.ietf.org ([2001:67c:370:128:581b:8d37:f5cd:23b9]) by smtp.gmail.com with ESMTPSA id t21sm23145330pfa.1.2016.11.15.18.52.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 18:52:24 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_CDD16B46-38D0-4FB1-96D4-CE2EBA908673" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: References: To: LISP mailing list list Date: Wed, 16 Nov 2016 03:52:21 +0100 X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [lisp] RIPE NCC to Assign LISP EID Prefixes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:52:27 -0000 --Apple-Mail=_CDD16B46-38D0-4FB1-96D4-CE2EBA908673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, here is the official announcement by RIPE NCC concerning the EID block. Ciao L. >=20 > -------- Forwarded Message -------- > Subject: [ncc-announce] [news] RIPE NCC to Assign LISP EID = Prefixes > Date: Tue, 15 Nov 2016 15:08:36 +0100 > From: Andrew de la Haye = > To: ncc-announce@ripe.net >=20 > Dear colleagues, >=20 > =46rom today, the RIPE NCC performs registry functions for IPv6 = Endpoint=20 > ID (EID) prefixes for Locator/Identifier Separation Protocol (LISP). >=20 > LISP is an experimental "map-and-encapsulate" protocol developed by = the=20 > Internet Engineering Task Force's (IETF's) LISP Working Group: > https://datatracker.ietf.org/wg/lisp/documents/ = >=20 > The IANA has assigned an IPv6 prefix for LISP EID space in accordance=20= > with RFC7954, which the RIPE NCC is now managing in accordance with = RFC7955. >=20 > Interested parties can request this space from the RIPE NCC via the = LISP=20 > EID Request Form: > https://www.ripe.net/manage-ips-and-asns/ipv6/lisp/lisp-request-form = >=20 > LISP EID assignments are provided free of charge. RIPE NCC membership = is=20 > not required to receive a LISP EID assignment. >=20 > This is a temporary prefix for a trial period of three years. In=20 > accordance with RFC7955, all assignments will be removed after 31 = August=20 > 2019. > The RIPE NCC website contains more information regarding LISP EID: > https://www.ripe.net/lisp >=20 > Kind regards, > Andrew de la Haye > Chief Operations Officer > RIPE NCC >=20 --Apple-Mail=_CDD16B46-38D0-4FB1-96D4-CE2EBA908673 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi All,

here is the = official announcement by RIPE NCC concerning the EID = block.

Ciao

L.


-------- Forwarded Message --------
Subject: [ncc-announce] [news] RIPE NCC to Assign LISP = EID Prefixes
Date: Tue, 15 Nov 2016 15:08:36 +0100
From: Andrew de la Haye <ripencc-management@ripe.ne= t>
To: ncc-announce@ripe.net 


Dear colleagues,

=46rom today, the RIPE NCC performs registry functions for IPv6 Endpoint=20=

ID (EID) prefixes for Locator/Identifier Separation Protocol (LISP).

LISP is an experimental "map-and-encapsulate" protocol developed by the=20=

Internet Engineering Task Force's (IETF's) LISP Working Group:
https://datatrack=
er.ietf.org/wg/lisp/documents/

The IANA has assigned an IPv6 prefix for LISP EID space in accordance=20
with RFC7954, which the RIPE NCC is now managing in accordance with =
RFC7955.

Interested parties can request this space from the RIPE NCC via the LISP=20=

EID Request Form:
https://www.ripe.net/manage-ips-and-asns/ipv6/lisp/lisp-request-form

LISP EID assignments are provided free of charge. RIPE NCC membership is=20=

not required to receive a LISP EID assignment.

This is a temporary prefix for a trial period of three years. In=20
accordance with RFC7955, all assignments will be removed after 31 August=20=

2019.
The RIPE NCC website contains more information regarding LISP EID:
https://www.ripe.net/lisp

Kind regards,
Andrew de la Haye
Chief Operations Officer
RIPE NCC

= --Apple-Mail=_CDD16B46-38D0-4FB1-96D4-CE2EBA908673-- From nobody Tue Nov 15 18:58:05 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB73129529 for ; Tue, 15 Nov 2016 18:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QluwaPL1QQZ8 for ; Tue, 15 Nov 2016 18:58:02 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB97129593 for ; Tue, 15 Nov 2016 18:58:02 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 3so73772999pgd.0 for ; Tue, 15 Nov 2016 18:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=G82sNjPD/lYXfuDMnmK0nBBxK+nUeEwW0CvLxVORjog=; b=l+KnguQ7quwR1r8FqNKV4KETmmyLFsX5tBEtyKYbSsUMFM9mC3b0ki+3fLRxtod9eC 2FjwVWo9j77hNoCjgXV+AigaF7e2Rrq3dASIV05OL+NyoLkKazFRWIK3zmBBO1fTaI6A ASvyQUT14AvyTxpzxpW9tNvrGJ8AgY9YrlQkXp1RHZiyp7qzYfLazeC+PM3ZQq9XWas1 OjzVFnzh42+4h24Q6Nv+ApDDye0DRcxrq1XqOSpZ10QAqvE9nsLqtz97CYlELb2LPIRF VRKeBcOX7R84dNj/LJDGmslRxUUnxxzzq3RXKlBs8wPCPdWPdiRFjSSMNqA/BBdA2i/q Baeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=G82sNjPD/lYXfuDMnmK0nBBxK+nUeEwW0CvLxVORjog=; b=OpvDN9VP17fCRyRrWe6LDn4foB/Lxx5sUhF1eM3KAlDBKoFYmeHchJrJmdtX2FlCoy hS6GDANrgywnT+D6jlLkSCq+sQsSivKKq+POMUkvNKA3q7DU93jjZNNWa/cJ/Hc7OhMk yV8zE0DJ3cpoN5pfIbtz8YLAOmN2+1AYgJv9wLbBNBThsY+94c+Weh4pZtE55iqUNSGi IKlW9GNd1RrLiZOJsd4PdpfZyXKkSWC7ejg0hoPWR8PJN1NnIY8/EGPCIIhMpEVY/2if L28FYs3pSH/Fqc+g3+CW3uSDlXu95xy2QjVbV97MoRJlSfMgnf+SfzE1j6wkgsMq3WCD as+A== X-Gm-Message-State: ABUngvfxTIlVnz5h+pD6XWRUQgw7fvx6U8kkWuESEgTDpuho2kf4A2RnWkg7bJwTkcjofw== X-Received: by 10.98.211.135 with SMTP id z7mr1308560pfk.109.1479265081220; Tue, 15 Nov 2016 18:58:01 -0800 (PST) Received: from t2001067c03700128581b8d37f5cd23b9.v6.meeting.ietf.org ([2001:67c:370:128:581b:8d37:f5cd:23b9]) by smtp.gmail.com with ESMTPSA id r194sm47157961pfr.94.2016.11.15.18.57.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 18:57:59 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_E79A79C2-CB2C-4F37-BB4B-A39523C815AE" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Wed, 16 Nov 2016 03:57:54 +0100 To: LISP mailing list list X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org Subject: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:58:03 -0000 --Apple-Mail=_E79A79C2-CB2C-4F37-BB4B-A39523C815AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, The chairs received a request for the following document to be adopted as a WG item: https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ = Here starts a 14 day call for adoption, this call will end on Wednesday the 30 November, 2016. Please email the WG list stating whether or not you support acceptance. If you email to support the acceptance of this document as a WG item, = please also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. Sitting in silence does not indicate support, please respond = appropriately. The Chairs Joel & Luigi= --Apple-Mail=_E79A79C2-CB2C-4F37-BB4B-A39523C815AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks,

The = chairs received a request for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bi= s/

Here starts a 14 day call for adoption, this call will end = on
Wednesday the 30 November, 2016.
Please email the WG list stating whether or not you support = acceptance.

If you email to support the = acceptance of this document as a WG item, please
also = indicate if you are able and willing to either contribute to, = or review, (or both) the draft.

Sitting = in silence does not indicate support, please respond appropriately.


The Chairs
Joel & = Luigi
= --Apple-Mail=_E79A79C2-CB2C-4F37-BB4B-A39523C815AE-- From nobody Tue Nov 15 18:58:19 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3A5129529 for ; Tue, 15 Nov 2016 18:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRHabnDIuiOk for ; Tue, 15 Nov 2016 18:58:16 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E9F1295FA for ; Tue, 15 Nov 2016 18:58:16 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id x23so70894613pgx.1 for ; Tue, 15 Nov 2016 18:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=wrzJuDMfxJ+/qA7d1GGuiVimixxKSX4WDDmJId20PNc=; b=bBw69xF9jWNwn8p+3liO/dfZcbEsROnXqGyBVMQtC6RbDuhxR+aVQXJUxTttPYH/AI 30kCKPBeiMqBdbffllWqLAdmtvDTvT4puz+PEbi42Bvy1YnQaxH8q1MWMdZPqzQnn4WG oefTaq1H1CqszSOG/3jDZl8RyoELLO8yv1O6yuqZr205MHmF+wTadoHlykva0H3bMpU7 OmK5VnWaW1+EUuuwgp5nfGERS6KwpQ0DIhjVeByUF9498/togtkUovebPE8pZhsGmf1H 8n5nNTC6g2VR4y2XNMVJz+ANMuECMmrp2/zTsfh2umxuNYdljEkzvS5S6ii8dKVufBkk 6Hhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=wrzJuDMfxJ+/qA7d1GGuiVimixxKSX4WDDmJId20PNc=; b=AccNuiml7lxtraHb0QvEmm3zMZi0PggiYNHlqhKuuHVhX3UGeH2QscOOHW6OMAMjTD PHxf0ZSNfkmOgwSUj8K+P4A8BxhstNJ371WmCSqDX9GR770ztkjEfScovHcPm3qZYfJ3 ZLSjd3LgBB8VIwqrr9tQN+y5Lh7TQ3u0uXAQzI3RZNz+YpPbplBwOcYiXnxZ39nA5vwW 4B30/CpFJ/X5Ri7S5GxIRIYazbaYsllpw48oy0MnFJUAXCUWdP9+lFYnHlCeiWDCErSD ZEH4t+w28ktqrBIn4Q4r/ViqdESR2wP37FU+h/9orzuL78VZF2HXLU7GPh47OzY4rdXF Q3wA== X-Gm-Message-State: ABUngvex3a3ZCnhJBNDCIyRmofnkTA/cYu6uXjO0ni88f4DuJrCCQH0m42qANsg37748wA== X-Received: by 10.98.35.5 with SMTP id j5mr1279778pfj.91.1479265095760; Tue, 15 Nov 2016 18:58:15 -0800 (PST) Received: from t2001067c03700128581b8d37f5cd23b9.v6.meeting.ietf.org ([2001:67c:370:128:581b:8d37:f5cd:23b9]) by smtp.gmail.com with ESMTPSA id r194sm47157961pfr.94.2016.11.15.18.58.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 18:58:14 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_5ED2B366-3182-4F23-B837-41644874C9D8" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> Date: Wed, 16 Nov 2016 03:58:13 +0100 To: LISP mailing list list X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org Subject: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:58:17 -0000 --Apple-Mail=_5ED2B366-3182-4F23-B837-41644874C9D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, The chairs received a request for the following document to be adopted as a WG item: https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ Here starts a 14 day call for adoption, this call will end on Wednesday the 30 November, 2016. Please email the WG list stating whether or not you support acceptance. If you email to support the acceptance of this document as a WG item, = please also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. Sitting in silence does not indicate support, please respond = appropriately. The Chairs Joel & Luigi= --Apple-Mail=_5ED2B366-3182-4F23-B837-41644874C9D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks,

The = chairs received a request for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bi= s/

Here starts a 14 day call for adoption, this call will end = on
Wednesday the 30 November, 2016.
Please email the WG list stating whether or not you support = acceptance.

If you email to support the = acceptance of this document as a WG item, please
also = indicate if you are able and willing to either contribute to, = or review, (or both) the draft.

Sitting = in silence does not indicate support, please respond appropriately.


The Chairs
Joel & = Luigi
= --Apple-Mail=_5ED2B366-3182-4F23-B837-41644874C9D8-- From nobody Tue Nov 15 19:11:36 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1225C129621; Tue, 15 Nov 2016 19:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcuzarR4CmfD; Tue, 15 Nov 2016 19:11:32 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB7C12957F; Tue, 15 Nov 2016 19:11:32 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id i88so39698865pfk.2; Tue, 15 Nov 2016 19:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0oWSB3vQqHWOLeVsoKTbRlxO8ijIYsY60ZwTnhjifn8=; b=EXlEc1ViXgBbukTYftN5+KUqxrFKNxKD6G5s/tJlbTBsfjnvXC8ItE7yYFsJWeYfFw EzghV38+fThMlIh1UVRC6ppF7zVOyQ67YjQNsxnt0SsEkyt+Ch7LdUGkwNU3XF5e574R B2vtXuRXMZTOBMH2fGhsR39O+sdA0Dq9EdrSoEbu0mfw76btC/QbmzIG1HAW6RY7Fbfs tNi7T402L3RDMjMZwFyykkn+CSAekXNDgo62v5cYkxnHs/eEZer5TCxGs4bF51STUwOH 6eBd766hi3vjS4WvM7c9GjRsnueTsEmphA9LtkSPPfhgnjPD142MdsnYJnF+6LOJGR0d T2Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0oWSB3vQqHWOLeVsoKTbRlxO8ijIYsY60ZwTnhjifn8=; b=B3Ri3EULgkVpwxN9Qr+Z2sdc/ITiccvrBUsoiEGFC6bqdy7bmQS0CwYiM1FRuI9B8d PeGpTysXpSKfLYAq6mR7g3Q3hWd88JdUjHwz1NWbZss3uUruGPJpx6/c+Ke4i0noYKED MRQtuRrZXG3svBGYYjZZSY/5qBOFeNEdcl2oz74S+M6F2CppQczzBijr+dn9w5QUlOxD xeYRGkAFiOpB+Km5fI6GatESnk4zc8gnY14BHVmwwoPuFd37l9A05g5vK+qUx8Vn7nW/ 62TE1XVbxfth2/3xCA3yIza7wP/fAwQJh1PhECkAPBp3v8noj9lpwrYCIk2Xb5eW5Zu3 xxYw== X-Gm-Message-State: ABUngvcMBhlpTOroKEZR56th7YjpiVq85VjENgtkteOowEUxGJ31PpBvjEuHJkJp3BGQ2w== X-Received: by 10.99.149.22 with SMTP id p22mr3260474pgd.21.1479265891951; Tue, 15 Nov 2016 19:11:31 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:2ddf:a122:fd7a:15e9? ([2001:67c:370:128:2ddf:a122:fd7a:15e9]) by smtp.gmail.com with ESMTPSA id y200sm47377606pfb.16.2016.11.15.19.11.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 19:11:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FE0B95E2-BB76-4717-961B-EC38A5D78F7A Mime-Version: 1.0 (1.0) From: Damien Saucez X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Wed, 16 Nov 2016 12:11:27 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: To: Luigi Iannone Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:11:34 -0000 --Apple-Mail-FE0B95E2-BB76-4717-961B-EC38A5D78F7A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am in favor of the adoption. Willing to review.=20 Damien Saucez=20 > On 16 Nov 2016, at 11:57, Luigi Iannone wrote: >=20 > Folks, >=20 > The chairs received a request for the following document to be > adopted as a WG item: >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. >=20 > Please email the WG list stating whether or not you support acceptance. >=20 > If you email to support the acceptance of this document as a WG item, plea= se > also indicate if you are able and willing to either contribute to, or revi= ew, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriately= . >=20 >=20 > The Chairs > Joel & Luigi --Apple-Mail-FE0B95E2-BB76-4717-961B-EC38A5D78F7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am in favor of the adopti= on. Willing to review. 

Damien Saucez 

On 16 Nov 2016, at 11:57, Luigi Iannone <ggx@gigix.net> wrote:

Folks,

The chai= rs received a request for the following document to be
adopted= as a WG item:

https://datatracker.ietf.org/doc/draft-farinac= ci-lisp-rfc6830bis/

Here starts a 14 day call for adoption, this call will end o= n
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support accepta= nce.

If you email to support the acceptance of t= his document as a WG item, please
also indicate if you are abl= e and willing to either contribute to, or review, (or both) the draft.<= br class=3D"">
Sitting in silence does not indicate support, p= lease respond appropriately.


The Chairs
Joel= & Luigi
= --Apple-Mail-FE0B95E2-BB76-4717-961B-EC38A5D78F7A-- From nobody Tue Nov 15 19:11:50 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C69A129648; Tue, 15 Nov 2016 19:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTlC4ReaEMvQ; Tue, 15 Nov 2016 19:11:40 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34D8129621; Tue, 15 Nov 2016 19:11:40 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id f188so73586249pgc.3; Tue, 15 Nov 2016 19:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G0Gx7WnDtXVcPh5a5ZiXFMu4uGo0VJTl0iLaz6qAoCE=; b=fywrtPuyy0y14CYHN1p1xt5t7NwYDUAc5pvak9INowHsDmSCBnJ9IsdGyRoTzRUs9C 4KjoEr74Qe8UCHhExJY0tUKFxdrGYW7cB78+xXr/s/uV+4/o2HSL8d/+XP4QcHVZ6/bs VKXD0aJGskTxd4GvSA3FPwKUH1qGJky9rv784M2NyYD4umzRFxlsr77VPCO+4PmqP+jV W38weMm/W85LDwqap3kN+W9z2DA85hspxfNSyQhxQ/Zaji4xJ/d2dhguu9iE7QyBjxrC 8Yj/bf5hx45msDcPSyzDVUo0U6eOpM953eqkRkfpVSxZBj25YHOK8E+tPwDkjT+UqU8F RWxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G0Gx7WnDtXVcPh5a5ZiXFMu4uGo0VJTl0iLaz6qAoCE=; b=WHaDjZAtGDdDFu6zT9LbK1UY4zgpq6hP7QdZWZIJshJgZkO3jPoGuAKuTVlCRUpErt G+92s/0YaE86HXSo8qmQp3AwjyOtM1oydas7E2Wiokh09UcdA4xobfFLZACYvuEzuGf2 UXG4hTH3AiY1RYuSHCZogM5gDokGIF8wDIFdvJ2JeV4mBx3Ow+36YHlBWfEOfqwp/Cgi wOo0KJy3cXTH/IFcW5rBwSt9Ikvuwy+uCdjAJfoqNtYx7/3Aqi/+E+nN6l31aBfaI9Zq mihbngEpaf7AUXAhJ1ZXtjBKIOUJPmowyI+K8Vsx14zpMcV1duq3LA3eHqIo5lPGGIxz 7g6g== X-Gm-Message-State: ABUngvch3xTPlG06ZBdp6ysmaNvNll1fpHKNX6S70EWpz3mtaQySPlyTysTFGnZs6133+g== X-Received: by 10.98.35.5 with SMTP id j5mr1350629pfj.91.1479265900248; Tue, 15 Nov 2016 19:11:40 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:2ddf:a122:fd7a:15e9? ([2001:67c:370:128:2ddf:a122:fd7a:15e9]) by smtp.gmail.com with ESMTPSA id r194sm47232162pfr.94.2016.11.15.19.11.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 19:11:39 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-53520A1C-CCFB-4846-9321-5B0038146678 Mime-Version: 1.0 (1.0) From: Damien Saucez X-Mailer: iPhone Mail (13G36) In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> Date: Wed, 16 Nov 2016 12:11:38 +0900 Content-Transfer-Encoding: 7bit Message-Id: <9204BB7E-A64D-4877-AA3E-4E34E1FE022F@gmail.com> References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> To: Luigi Iannone Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 03:11:45 -0000 --Apple-Mail-53520A1C-CCFB-4846-9321-5B0038146678 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am in favor of the adoption. Willing to review.=20 Damien Saucez=20 > On 16 Nov 2016, at 11:58, Luigi Iannone wrote: >=20 > Folks, >=20 > The chairs received a request for the following document to be > adopted as a WG item: >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. >=20 > Please email the WG list stating whether or not you support acceptance. >=20 > If you email to support the acceptance of this document as a WG item, plea= se > also indicate if you are able and willing to either contribute to, or revi= ew, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond appropriately= . >=20 >=20 > The Chairs > Joel & Luigi --Apple-Mail-53520A1C-CCFB-4846-9321-5B0038146678 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am in favor of the adoption. Willing t= o review. 

Damien Saucez 

On 16 Nov 2= 016, at 11:58, Luigi Iannone <ggx@gigix.= net> wrote:

Folks,

The chairs received a request f= or the following document to be
adopted as a WG item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/=

Here s= tarts a 14 day call for adoption, this call will end on
Wednes= day the 30 November, 2016.

Please email t= he WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG it= em, please
also indicate if you are able and willing to either= contribute to, or review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropria= tely.


The Chairs
Joel & Luigi
= --Apple-Mail-53520A1C-CCFB-4846-9321-5B0038146678-- From nobody Tue Nov 15 22:01:56 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBFC12968C; Tue, 15 Nov 2016 22:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LefN8tmugRJH; Tue, 15 Nov 2016 22:01:53 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A4B1295AB; Tue, 15 Nov 2016 22:01:53 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id d2so40896194pfd.0; Tue, 15 Nov 2016 22:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ljIdQvvaoV03a4UDbfqHoaVszkn4h/na7P9V4OxE7fk=; b=mRZvj5ZvgPf6sEeGw/R7/IiCdTAJ+RKOkdi8HD/NZtQq4tfprSYsxBqPfwByuZRtsO 54fpXloZ6obNWZQGO0gu3mGv4XwXyJrDia1utEBdMstUbpUEnjxvKyxVE6FfmfBAIFht rzPaTSgCLgdfjZBnzQJR9i61Q1SUcX+hVVhoAxcUbZzdTPcOlUEGiQMLNRdGhGVfc7We oEhKM6RgNFNzeMTzVLwlVcoVh3l4YcJUjN/q55EGre102jfWQUGCRkTi2N1gGO5asXB/ /cJ8xk/sRMWe/6lhOqJ2rV0nNk08sjXGqJIz9jq1fYto2EzRO10TYOBv+4y1rmf+cyuG j1hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ljIdQvvaoV03a4UDbfqHoaVszkn4h/na7P9V4OxE7fk=; b=Aj1v9K5KugaJswzYc7hKaoHCGeuAaSH7nCDuINvzUED7XMC0kPFh5v8FPR1Zb+x66n 2qcFQ2yi0N2MWGpftaL+AMc9zS1QGIb0hTdPgxgY+aOCD5Aqu9uKDD9I6JAezCu8cD9y TDlbLwBiuEeK8rL87zZ00fhpN2Q5Ru8fI8JJwIYJNZAldKDEVb8XQEuHHDNauhyocT0N Qjj5rkjIBmeEqGaIX/uX1djz6hM3hplKCtWsY7IVxO0pLicMC+NmYugCTtJJrlot1XiA cG81XXqSg5LVDixzi0zWaLF8qL5ySHPVbG8SnNshc289te3bGrpZaUVpRKSEsOAPYD7H 9cyA== X-Gm-Message-State: ABUngvfR8ddLVykTwWfjodPDNzPZOxC/JWEd3ovCmfPuUyMcABwkVvStxFCLfNbn7n3SrQ== X-Received: by 10.99.43.8 with SMTP id r8mr4564026pgr.83.1479276113076; Tue, 15 Nov 2016 22:01:53 -0800 (PST) Received: from t2001067c03700144d8ab64a80b43e604.hotel-wired.v6.meeting.ietf.org ([2001:67c:370:144:d8ab:64a8:b43:e604]) by smtp.gmail.com with ESMTPSA id 131sm48807799pfx.92.2016.11.15.22.01.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 22:01:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: Date: Tue, 15 Nov 2016 22:01:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <288E3FE2-CC7F-4BCF-A2F1-562672E311DA@gmail.com> References: To: Luigi Iannone X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:01:55 -0000 Since this is in the WG charter, I am in favor. Dino > On Nov 15, 2016, at 6:57 PM, Luigi Iannone wrote: >=20 > Folks, >=20 > The chairs received a request for the following document to be > adopted as a WG item: >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. >=20 > Please email the WG list stating whether or not you support = acceptance. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond = appropriately. >=20 >=20 > The Chairs > Joel & Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Tue Nov 15 22:02:28 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088712969B; Tue, 15 Nov 2016 22:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UosFSGMPPsY3; Tue, 15 Nov 2016 22:02:25 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555D8129691; Tue, 15 Nov 2016 22:02:25 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id x23so72664882pgx.1; Tue, 15 Nov 2016 22:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kqukoP2D61FGWRIU/+WQz4U8VIs85+Duk5QoeLpi5Cw=; b=b4wBFKBdAxlhJ0ephpw5rdiV5tQkC8Dmf9HkrhAj6h/Jah+gdf+oeax/FGsz8ylYzf jHFgeEkW+bhzpLT8J3YxL1Mo+bD5WGgfOcylA+SB15nbtoO4vUka8c4ztYfPBly6WM6s KlWWXUdaaG6FW+TBcne2GVcCdj2AEqnWiBAxPJthj41zSeXRV9oIi+sTXt8FCScl+mYo 7HPUeDzhmB3Sa2WSmoRtXnJyj0WjxlfnMPGiH4sCgI7TomfvMeUuy+5+r9kPRVFn2juC xqoThMZU8VGbC4M6K6COTEZnhkmdYjS5u5jCMb6YpGyaEI1NUcotCthJlQsSV96VIKWu f1XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kqukoP2D61FGWRIU/+WQz4U8VIs85+Duk5QoeLpi5Cw=; b=X8QAngHiCogIM0C74vhMEyNPCDWlQRGkDAwkY9kNI0pCg2xUIi2ZrKqkcAHC4w9HFH gJ/mkb166EQ1agUDKIgY4TZHdBK8+7JWluPM+maNkBx7GLdcm8+mJv9ERrhciv8TxbQl mF9FrGx0FA2MGB5ffTaZ7VMzHyArh2HfRbt+QXxrcDd2aG/GTcTvaqEm0UPBGBUQ8pHR yFAo46D2QMm4UQ1+Ncjy5w/BfrVDVNdGb3zHw0NEs4y8i8TVVYvLfwZ+KcwZ6vJOcNE3 LEOQ1sC/UbQfZjwG4GVBEuzTl/R/n362FMQD18RnmnRr5YdUvnfUbH2tw5njykiGCjwV EyYw== X-Gm-Message-State: ABUngvcy5hZil56CwHv5kmIupK9FkqACa4CGuV1mu5TBhWGhSQJ7htr4VM5IANeNbATCaA== X-Received: by 10.99.251.5 with SMTP id o5mr4536940pgh.160.1479276145017; Tue, 15 Nov 2016 22:02:25 -0800 (PST) Received: from t2001067c03700144d8ab64a80b43e604.hotel-wired.v6.meeting.ietf.org ([2001:67c:370:144:d8ab:64a8:b43:e604]) by smtp.gmail.com with ESMTPSA id 131sm48807799pfx.92.2016.11.15.22.02.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 22:02:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> Date: Tue, 15 Nov 2016 22:02:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <12E41B99-AD12-4126-A21E-D348E44BAD65@gmail.com> References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:02:26 -0000 Since this is in the WG charter, I am in favor. Dino > On Nov 15, 2016, at 6:58 PM, Luigi Iannone wrote: >=20 > Folks, >=20 > The chairs received a request for the following document to be > adopted as a WG item: >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. >=20 > Please email the WG list stating whether or not you support = acceptance. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond = appropriately. >=20 >=20 > The Chairs > Joel & Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Nov 16 00:38:16 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25FE12954D for ; Wed, 16 Nov 2016 00:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.998 X-Spam-Level: X-Spam-Status: No, score=-15.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg32L6oHp0qd for ; Wed, 16 Nov 2016 00:38:13 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0F01294A9 for ; Wed, 16 Nov 2016 00:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3660; q=dns/txt; s=iport; t=1479285493; x=1480495093; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=rk0J7c63w/AORrXS+CVEf5dL6Kr1ojmLwY9EPsHutPo=; b=Q4lNMQ/iDVG0WRwMYNQfVtU1f76GCFL1JayXiNPJjkDf8Hu/qTYHacZ8 R1jxW0QDNhXVLOi8fbrlQ0bJwyX7vmQDS6sJrJUTbVCYpr6cF9AodI8Yc qAYf/ZuALzaA4W2Y42pv7Nz+mYnf9QJjuVdDtENWR3PwKzSS3ghP5AYfY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBABHGixY/xjFo0heGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAXcsVI0+lw6PRoUbggcdAQqFewKCUBQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBGlEbCwQULicwEwYCAQGIaA60Gi+LNgEBAQEBAQQBAQEBAQEBAR+GP?= =?us-ascii?q?IF9gl2EGhEBaIUVBY9bhH6FaIY9iieBb0+EJ4MchiGNS4QKHjddDhELHIUsLzS?= =?us-ascii?q?FPYItAQEB?= X-IronPort-AV: E=Sophos; i="5.31,647,1473120000"; d="scan'208,217"; a="65254683" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 08:38:06 +0000 Received: from [10.70.234.102] ([10.70.234.102]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uAG8c5Qq022398 for ; Wed, 16 Nov 2016 08:38:05 GMT To: lisp@ietf.org References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> From: Fabio Maino Message-ID: <7cde8be9-b4d2-3d55-e1e8-4289d0f0ce7f@cisco.com> Date: Wed, 16 Nov 2016 17:38:05 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> Content-Type: multipart/alternative; boundary="------------9020E9A8924D08979E5ECF2A" Archived-At: Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:38:15 -0000 This is a multi-part message in MIME format. --------------9020E9A8924D08979E5ECF2A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I support adoption. Fabio On 11/16/16 11:58 AM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > _https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/_ > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > > The Chairs > Joel & Luigi > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------9020E9A8924D08979E5ECF2A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I support adoption.

Fabio


On 11/16/16 11:58 AM, Luigi Iannone wrote:
Folks,

The chairs received a request for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/

Here starts a 14 day call for adoption, this call will end on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, please
also indicate if you are able and willing to either contribute to, orreview, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.


The Chairs
Joel & Luigi


_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


--------------9020E9A8924D08979E5ECF2A-- From nobody Wed Nov 16 00:38:43 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2A129458 for ; Wed, 16 Nov 2016 00:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.998 X-Spam-Level: X-Spam-Status: No, score=-15.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM4PAYSLMtp1 for ; Wed, 16 Nov 2016 00:38:39 -0800 (PST) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF261295A0 for ; Wed, 16 Nov 2016 00:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3674; q=dns/txt; s=iport; t=1479285518; x=1480495118; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=WdQmB1VUMBLJrnxu6MrbJoSE4Yspjkh/5S4AH6vrYmQ=; b=WMsh1wa5wbOl2MCqmWTSVS3cd9pMf4xbHCr35SYcC2GyFp4JuNn76wgS O8OGG4hst7i4HgQOKV6mrr61Sf+pXSqtQiBkxWKVLOm3jeAZYQwVaau6V qRuswB8MyysC2rdXwbQHerCN0tWmPCUQ/g2NzZsouWqVUqQEZKtAjj7aD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBACvGSxY/xjFo0heGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzcBAQEBAXcsVI0+lw6PRoUbggcdAQqFewKCUBQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBGlEbCwQULicwEwYCAQGIaA60GC+LNgEBAQEBAQQBAQEBAQEBAR+GP?= =?us-ascii?q?IF9gl2EGhEBaIUVBY9bimaGPYongW9PhCeDHIYhjUuECh43XQ4RCxyFLC80hT2?= =?us-ascii?q?CLQEBAQ?= X-IronPort-AV: E=Sophos; i="5.31,647,1473120000"; d="scan'208,217"; a="39127314" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 08:38:32 +0000 Received: from [10.70.234.102] ([10.70.234.102]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uAG8cVIb022444 for ; Wed, 16 Nov 2016 08:38:31 GMT To: lisp@ietf.org References: From: Fabio Maino Message-ID: Date: Wed, 16 Nov 2016 17:38:30 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3F5404B8A98F3D9811FC233F" Archived-At: Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:38:42 -0000 This is a multi-part message in MIME format. --------------3F5404B8A98F3D9811FC233F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I support adoption of this draft. Fabio On 11/16/16 11:57 AM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > _https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/_ > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond > appropriately. > > > The Chairs > Joel & Luigi > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------3F5404B8A98F3D9811FC233F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I support adoption of this draft.

Fabio

On 11/16/16 11:57 AM, Luigi Iannone wrote:
Folks,

The chairs received a request for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/

Here starts a 14 day call for adoption, this call will end on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, please
also indicate if you are able and willing to either contribute to, orreview, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.


The Chairs
Joel & Luigi


_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


--------------3F5404B8A98F3D9811FC233F-- From nobody Wed Nov 16 04:08:22 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3161293DA; Wed, 16 Nov 2016 04:08:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147929810082.7349.12867505303858240674.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2016 04:08:20 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-sec-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 12:08:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol of the IETF. Title : LISP-Security (LISP-SEC) Authors : Fabio Maino Vina Ermagan Albert Cabellos Damien Saucez Filename : draft-ietf-lisp-sec-12.txt Pages : 22 Date : 2016-11-16 Abstract: This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-sec-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-sec-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 16 04:12:47 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959F212944D for ; Wed, 16 Nov 2016 04:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.999 X-Spam-Level: X-Spam-Status: No, score=-15.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGHQd8xZduGI for ; Wed, 16 Nov 2016 04:12:45 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6114B1293DA for ; Wed, 16 Nov 2016 04:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1754; q=dns/txt; s=iport; t=1479298364; x=1480507964; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=y3s1DfihTWSeWYzw6TaSfEEuD9NOeTcp/i+o3i3UOk0=; b=D6NmXQp2lIds5VzcKN4PXYzADU4PZ2q9aW/4U2aBZMmODrqyvWIwvoTv WrMVnIF7fFNzi/+dJOJ2wupymVXtGQMfR1MS/CWKlWtCbnjYlg1w0j4Z8 tYoiwAdGPoXe+PXSLZSdcmBq8+Gld0IPFKbDtzC9o8U+/zysl3EKXgHF8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAgCsTCxY/xjFo0heGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAXcsVI0+lw6UYoIHHQuFeQKCWBQBAgEBAQEBAQFiKIR?= =?us-ascii?q?iAQEEAQEBNTYbCxguJzATBgIBAYhoDrQ3i2cBAQEBBgEBAQEBIoY8gX2CXYMLg?= =?us-ascii?q?gqFFQEEj1yKZoY+iiqBcE+EJ4MchiGNTYQKHjdrEQsTCYMkHIFsLzSHagEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,647,1473120000"; d="scan'208";a="65259412" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2016 12:12:23 +0000 Received: from [10.70.231.190] (tky-vpn-client-231-190.cisco.com [10.70.231.190]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uAGCCM1s019569 for ; Wed, 16 Nov 2016 12:12:23 GMT To: lisp@ietf.org References: <147929810082.7349.12867505303858240674.idtracker@ietfa.amsl.com> From: Fabio Maino Message-ID: <04e895c9-d54e-a18c-6ed7-aa4dcfa40894@cisco.com> Date: Wed, 16 Nov 2016 21:12:22 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147929810082.7349.12867505303858240674.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lisp] I-D Action: draft-ietf-lisp-sec-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 12:12:46 -0000 As discussed this morning we would like to propose this document for last call. Thanks, Fabio On 11/16/16 9:08 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Locator/ID Separation Protocol of the IETF. > > Title : LISP-Security (LISP-SEC) > Authors : Fabio Maino > Vina Ermagan > Albert Cabellos > Damien Saucez > Filename : draft-ietf-lisp-sec-12.txt > Pages : 22 > Date : 2016-11-16 > > Abstract: > This memo specifies LISP-SEC, a set of security mechanisms that > provides origin authentication, integrity and anti-replay protection > to LISP's EID-to-RLOC mapping data conveyed via mapping lookup > process. LISP-SEC also enables verification of authorization on EID- > prefix claims in Map-Reply messages. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lisp-sec-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-sec-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Wed Nov 16 04:24:59 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0E11296AC; Wed, 16 Nov 2016 04:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAg_eM-hBDXG; Wed, 16 Nov 2016 04:24:54 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E32012968F; Wed, 16 Nov 2016 04:24:54 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id a197so235950086wmd.0; Wed, 16 Nov 2016 04:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pj+C0P+itKjm2z+QUYEpTwsFsjxUcyBYPMZsh8ckRYU=; b=ggMDkjsXpJYGFQ90zIZeqW822s9jX2XytPkAuXM9ToBZmFTRQimiEXDEO5aHfTAfrP rlR3R+RthXesAjXJfIJjzDVU1N9NMiDxmC3aw0v9rtOjkEQ5285fpPPYcc/t35K+6nRE ynzHFwcLoBPS/BEe0xHE+iJwkO7/LSu0jERGiHAMV8EWblfsPIw7fUbBgR0PmGaLI3U2 m1IIqgTc6RHQfUrXmonVsYMj+AXJznvWLgXil0nh4Fs4KN3MwIsK7d4peBCoccv4XlAC C7zikkqKx42HP9nXrcr5d/aXcX0yT72cR8R7HQAWIU6qdWafrq/DS58joVwP3o8rEPUt hKaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pj+C0P+itKjm2z+QUYEpTwsFsjxUcyBYPMZsh8ckRYU=; b=bJiM4LoHw3Hftop1Pk+lBDz6kDNOJ21YDiA8t3gDnfuXU1r/hWXdN/c9zyubCImZYO 0H+tKBtiyReca1KeLpga7M9lFN1EprZFaYIetkwska7iYtxT7YiWHfSygxqZjzbhWc2s zyiag4+nNEzO9DtczL3KMJD+Kc9XUCUPGV+hKlAUse6FjjpIOjKW2Ld3HqYaHgeR21TK 54vvRhLJH8HfOH4WV08KzJNxGBf384m9PVriKfY6pN+6wkk0XFiyokg0nzcDf4bROX0h MKLUSaAM9UQYglmxG6N3M7NaTHC5X7aJQ3pWieQeCqaGufYkvplmyTAkAYq0x3ghNFSV KN3g== X-Gm-Message-State: ABUngvfU5CPS27VUe3XSvJg1si3KssWqqRW70cfQ+mnSlMpDIdURN8l4auJ6b17mmS+7oWIj4lzn0OFPjrtNvQ== X-Received: by 10.194.172.42 with SMTP id az10mr1776840wjc.145.1479299093122; Wed, 16 Nov 2016 04:24:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.142.200 with HTTP; Wed, 16 Nov 2016 04:24:52 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Wed, 16 Nov 2016 13:24:52 +0100 Message-ID: To: Luigi Iannone Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 12:24:56 -0000 On Wed, Nov 16, 2016 at 3:57 AM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. I support adopting this document as a wg item. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Wed Nov 16 04:25:39 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC11296AC; Wed, 16 Nov 2016 04:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac0SnwQwswtH; Wed, 16 Nov 2016 04:25:36 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C631612968F; Wed, 16 Nov 2016 04:25:35 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id g23so236230760wme.1; Wed, 16 Nov 2016 04:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+RG4CdaC+mqvfQkCYdqkKK57uD24Exqsx6AuHQ9H9lw=; b=ZX+R743hLKRPxiiBaM1cVkOBF5ozgFNfUMeSqn2o1/iBafp/9nkuwxycHVx3ZPbHFS kE7uLPKiy+Kt6w7gaanCZvOpxC8N6dIAsT+znMIw37R8fDvGhDDBh+UHMTtmRX9F3+YV 3uFyZYKroVD4g7FUJH4OvwWA7aXqEmwV7ep4CDFlJ5fHLBNwruOi1uhl2Yd9Rcn1/rnJ /4l7XfI4XShhPtQtauYYBufBWbrNkUvEFEznp4PlcXJawQjvhakF1cVXt8jC9Qvor/Jk uSMSYm9VfAAe2MkHKO6F9XUgiBGOEBzmqndTR4ihj4IRir5iE3OFqsw9d/Qt6LuO587z WOsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+RG4CdaC+mqvfQkCYdqkKK57uD24Exqsx6AuHQ9H9lw=; b=PvAQqHCv47odrU5sO/xS7SN71Z5PErfqPgDHlzXXWZZxeJ1HuNE0AnLeqwaONF9vaf svCk+tBZ7hNmP/3O50w6yl+zvzolQ5Y5H8YWXsFe0CikKFYiQT699XacNI9A5ucTz64T dX1foAxTSDQGEtOMdvWfcBotW/bE3CQHzLKG2oBue50URbhtAR9+tY+vvgxuoaCjVlAx QhUDrL9raJitEj4VKrG0O4O+KZ6YNUv8tz+RsIMIIQ51S8qhXPfrHV/rG0cu8ABsT3g2 22rtJdrLXLS/YCvWwnV6frrWXpKJ65U2GaALwsqhJ/KEazbaxjmVDGtlAqdpPTRGONbo nLeA== X-Gm-Message-State: ABUngvd6HXZ2TxRkzSqkbwe/3AM2l+KtqtmxKl/DumOR7vdtWLQhRn+5RL0yasVkJUWzzG+v3F5n1SB2Q2gyHg== X-Received: by 10.28.153.201 with SMTP id b192mr9947568wme.61.1479299134302; Wed, 16 Nov 2016 04:25:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.142.200 with HTTP; Wed, 16 Nov 2016 04:25:33 -0800 (PST) In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= Date: Wed, 16 Nov 2016 13:25:33 +0100 Message-ID: To: Luigi Iannone Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 12:25:37 -0000 On Wed, Nov 16, 2016 at 3:58 AM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, or > review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. I support adopting this as a WG item. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From nobody Wed Nov 16 12:47:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DF8129866; Wed, 16 Nov 2016 12:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMEAKepLv75T; Wed, 16 Nov 2016 12:47:29 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C5C12985F; Wed, 16 Nov 2016 12:47:29 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id t125so137740529ywc.1; Wed, 16 Nov 2016 12:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+TFZt/hd6ous+1mzAbxHA3GZCNCIK238WG8sxVc0NNg=; b=VRP85+CoHkz4PMcKotAodSEddJi6sPu71UK7AtI8yavOiAjt4sXGzEHhVc61vH3kcd Qpf3+0uMo31uKTjcLhT67RvryFJtujrYapfQucgQMZrzkJbyWROYtYNYJZgmi4B6cKMC Xrf52eGmxRnftFa3qLLpRzWFwVsLG4z/s0YXMkLIVR/BM52MtJyrNregZ5CNXYORGf5x WMBUFPyNqFEbEatSRlkHznZ0wNSwCygRWegVI643oMw3Cc5WRkM8z1LMBfYQ82aKgKVt zWwApRCOIKiiTvaBh4SlUcI1KDg/nMUb4C8KKucjxsNHpogjYqJEj17wWAE3fLpiV8PN pkBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+TFZt/hd6ous+1mzAbxHA3GZCNCIK238WG8sxVc0NNg=; b=ha6j0Ic/TT7Ywsv1FxR5aipT8emIWOErAARl3U9+CosBTZMKspoPekMkSesFQjslMj o5umKERpfPP9+VhWH3wQ6dKPyIouiyXb0tOPGDRSSFwtiAcgQ/M4Zr0D/8B6Xntgorg2 bn8ICKHaGMQ91Ei4TpM/CBaRbhu5mHOwX3ZTXUAQHXY8p1XDZq5QdmYVpXYO22lE2zCF b2fWgWueIQvhMLroH5pTrC5kwEf0agilBZadi3Nk0j+PgnjlTnCEPGGS9oaZ1dNhtu00 3vpR5EMh9QuKNvSqFBm+PG8FYbp2xjUlmRS0opRpbIlgeWIB8Xp+z2ZZvRd3Hw4pe2Kc 6jyA== X-Gm-Message-State: ABUngvdVFDTS81Hr4VFRlV8DpZvieaGtJnKhzVfs7pqir+8cF59miOkiy1HwZwQRSN+QzaE+moj7RQmNEo+46Q== X-Received: by 10.157.19.27 with SMTP id f27mr3696162ote.226.1479329248462; Wed, 16 Nov 2016 12:47:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.20.111 with HTTP; Wed, 16 Nov 2016 12:47:08 -0800 (PST) In-Reply-To: References: From: Alberto Rodriguez-Natal Date: Wed, 16 Nov 2016 12:47:08 -0800 Message-ID: To: Luigi Iannone Content-Type: multipart/alternative; boundary=001a113d10e25c4dc50541712e8e Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 20:47:31 -0000 --001a113d10e25c4dc50541712e8e Content-Type: text/plain; charset=UTF-8 Support On Tue, Nov 15, 2016 at 6:57 PM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > *https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ > * > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > > The Chairs > Joel & Luigi > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a113d10e25c4dc50541712e8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support

On Tue, Nov 15, 2016 at 6:57 PM, Luigi Iannone <ggx@gigix.n= et> wrote:
Folks,

The chairs received a request= for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/do= c/draft-farinacci-lisp-rfc6830bis/

=
Here starts a 14 day call for adoption, this call will end on
Wedne= sday the 30 November, 2016.

Please email the WG list stating = whether or not you support acceptance.

If you email to support the a= cceptance of this document as a WG item, please
also indicate if you are= able and willing to either contribute to, or=C2=A0review, (or both) the dr= aft.

Sitting in silence does not indicate support, please respond ap= propriately.


The Chairs
Joel &am= p; Luigi

______________________________________________= _
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


--001a113d10e25c4dc50541712e8e-- From nobody Wed Nov 16 12:47:55 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E00D129405; Wed, 16 Nov 2016 12:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxfVByp04nBB; Wed, 16 Nov 2016 12:47:51 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02E2129869; Wed, 16 Nov 2016 12:47:50 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id a10so138543971ywa.3; Wed, 16 Nov 2016 12:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZIOzjjikjW2ssqNMMAPFfRpbgEIJxVX+pZV4UtiZ0wg=; b=U1/CWZH9B0uSdsiHiJxx8JHz77BrQNEjuqXUUbOTcGVCAq06DCKWX8QHOCbRujAgur LJanqfSFjiwYWUhzW2BE9cfrHqPdZnXJdOS747QL1WqI3I9K69iRuvVF/fOsI5GMBA8S YPvIWa1BL3mOvAe93kegHE2wT1JI/7fHk6SX4QRU5nyBhNx/pjbY35kh2epCwWSWMt0C 02f757ld0BhUWffUeKSZ7zZh9pOiodLGmL06BA1s1ObnC/8g3+85epXQPEI6UiN3Xkig 6EqriGPuXm/dXFtrZI1fFx0Ii44pDS+mF2xC1YiejNPqTaf5ts92mj1VLhggkL30erGl GMxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZIOzjjikjW2ssqNMMAPFfRpbgEIJxVX+pZV4UtiZ0wg=; b=hOSIw8BorDVuMmJTK2rlUITew7MllZl8KMn/jM7PYeloazibe2bSHF2QC4Ngp8t2WI e/J+08mBgtGMKlfQaBHd/qil7JkfBMIZBHmmUSlfhLXI5Qte/Q7+W5bhBCOfTymdHgiu na0Nn1dcEs8ETQJVbSUqQMEHSrcaQqDCV27Po36KCCUkcQhaWV5szBLbWIap5BwPlWt2 3s7wcURG4CsK3dJ/PFt2lli1Bd7O/JRFvakxxV2diIAuuPRsKPxiCdR+9fcoPXFW5JSj 4KKX788+GPuBlgQFu5R1YAUQuHVdSPBerDael94018NNft9YzHmSNYfr+Ruh6aB9QciV 6g2Q== X-Gm-Message-State: AKaTC03rUVVx8WPrQqVlVQPk1hzK2ezxfsuMGpI3fC4haXjx+Dxl1SCKO+35PNmOwe/OPbH59hyllVtctVkQjQ== X-Received: by 10.157.19.124 with SMTP id q57mr3372838otq.33.1479329270131; Wed, 16 Nov 2016 12:47:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.20.111 with HTTP; Wed, 16 Nov 2016 12:47:29 -0800 (PST) In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> From: Alberto Rodriguez-Natal Date: Wed, 16 Nov 2016 12:47:29 -0800 Message-ID: To: Luigi Iannone Content-Type: multipart/alternative; boundary=001a1141b848a6f3e40541712f5c Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 20:47:54 -0000 --001a1141b848a6f3e40541712f5c Content-Type: text/plain; charset=UTF-8 Support On Tue, Nov 15, 2016 at 6:58 PM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > *https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ > * > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > > The Chairs > Joel & Luigi > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a1141b848a6f3e40541712f5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support

On Tue, Nov 15, 2016 at 6:58 PM, Luigi Iannone <ggx@gigix.n= et> wrote:
Folks,

The chairs received a request= for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/do= c/draft-farinacci-lisp-rfc6833bis/

=
Here starts a 14 day call for adoption, this call will end on
Wedne= sday the 30 November, 2016.

Please email the WG list stating = whether or not you support acceptance.

If you email to support the a= cceptance of this document as a WG item, please
also indicate if you are= able and willing to either contribute to, or=C2=A0review, (or both) the dr= aft.

Sitting in silence does not indicate support, please respond ap= propriately.


The Chairs
Joel &am= p; Luigi

______________________________________________= _
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


--001a1141b848a6f3e40541712f5c-- From nobody Wed Nov 16 15:45:10 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F571294E3; Wed, 16 Nov 2016 15:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvoW1U41j8Pz; Wed, 16 Nov 2016 15:45:08 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F107126579; Wed, 16 Nov 2016 15:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4489; q=dns/txt; s=iport; t=1479339907; x=1480549507; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7FwZZtdKR7Ld3esQSjwviNGzKACvCZGVKQIiE7XjTzo=; b=TbLUr+dGQrrc/e/qkcMrXdgnCMp1u2g/ozARkL4ubJ7M/hnF6wilLTIW +zX47ITLvi2DI26bbBGuW4XvLh6dKAuB0SLfglCopRhjzzEMxuvgrtYtV r+rWL3Apz+8eI3lKhgFHG4/zx2hvQ0ajcD9hepAmaN+pOjEnKUrdSMeWm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQAF7ixY/40NJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNEAQEBAQEfWIEAB403lw6PR4UbggcohXkCghM/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEHVELEAIBCAQKAwMBAigHMhQJCAIEAQ0FiGwOtQWLYgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFhjyEWoQbEQE8hUEFlFqFaAGGPYoqgXCEdok9jU2ECQE?= =?us-ascii?q?eN10qHIUdcoV5gSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,650,1473120000"; d="scan'208,217";a="170264890" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2016 23:45:07 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uAGNj7fC027676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 23:45:07 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 17:45:06 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 17:45:06 -0600 From: "Reshad Rahman (rrahman)" To: Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis Thread-Index: AQHSP7VQ27sOtUNV4EiKWi0782fQ2KDcWEKA Date: Wed, 16 Nov 2016 23:45:06 +0000 Message-ID: References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.242] Content-Type: multipart/alternative; boundary="_000_D452596A1F3E55rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 23:45:09 -0000 --_000_D452596A1F3E55rrahmanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption. I am willing to contribute or review. Regards, Reshad. From: lisp > on behalf = of Luigi Iannone > Date: Tuesday, November 15, 2016 at 9:58 PM To: LISP mailing list list > Cc: "lisp-chairs@ietf.org" > Subject: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis Folks, The chairs received a request for the following document to be adopted as a WG item: https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ Here starts a 14 day call for adoption, this call will end on Wednesday the 30 November, 2016. Please email the WG list stating whether or not you support acceptance. If you email to support the acceptance of this document as a WG item, pleas= e also indicate if you are able and willing to either contribute to, or revie= w, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. The Chairs Joel & Luigi --_000_D452596A1F3E55rrahmanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <159D83A7D578A04599EA92F464686FDF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I support adoption. I am willing to contribute or review.

Regards,
Reshad.

From: lisp <lisp-bounces@ietf.org> on behalf of Luigi Ianno= ne <ggx@gigix.net>
Date: Tuesday, November 15, 2016 at= 9:58 PM
To: LISP mailing list list <lisp@ietf.org>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
Subject: [lisp] Call for adoption d= raft-farinacci-lisp-rfc6833bis

Folks,

The chairs received a request for the following document to= be
adopted as a WG item:

https://data= tracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/

Here starts a 14 day call for adoption, this call will end = on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, pleas= e
also indicate if you are able and willing to either contribute to, or = review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.=


The Chairs
Joel & Luigi
 --_000_D452596A1F3E55rrahmanciscocom_-- From nobody Wed Nov 16 15:46:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553481293FF; Wed, 16 Nov 2016 15:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i89fMpMH5C1N; Wed, 16 Nov 2016 15:46:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE22126579; Wed, 16 Nov 2016 15:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4310; q=dns/txt; s=iport; t=1479339971; x=1480549571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Nq56/dXtrzWdxZ156+g2iI5vr+K5xucODlDncoOhr9s=; b=Tzl8tEiCoPnsPFCD9LH5KPmAildRawZZLfFGjLo5Y8fHxQrXS4UjechQ 3EXQnvrrnnpYnUCeZUX5CRJvYOJ9fpcwpnQ0YCm0nFJ+XJxi5QBd31U5U ilKH3NCzf7CCJKqiQd5ttdOkJr/qBxi/Nj8JgNdfQ5BcrHFBKteQa8KbY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQBh7yxY/4oNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNEAQEBAQEfWIEAB403lw6PR4UbggcohXkCghQ/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEHVELEAIBCAQKAwMBAigHMhQJCAIEAQ0FiGwOtQmLYgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARcFhjyEWoQbEQE8hUEFlFqFaAGGPYoqgXCEdok9jU2ECQE?= =?us-ascii?q?eN10qHIUdcoV5gSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,650,1473120000"; d="scan'208,217";a="175717491" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2016 23:46:10 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uAGNkAUc022605 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 23:46:10 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 17:46:09 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 17:46:09 -0600 From: "Reshad Rahman (rrahman)" To: Luigi Iannone , LISP mailing list list Thread-Topic: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis Thread-Index: AQHSP7VFqImGcbrsaE6qyx5rj1XhoaDcWHaA Date: Wed, 16 Nov 2016 23:46:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.242] Content-Type: multipart/alternative; boundary="_000_D45259D81F3E5Arrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "lisp-chairs@ietf.org" Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 23:46:12 -0000 --_000_D45259D81F3E5Arrahmanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. From: lisp > on behalf = of Luigi Iannone > Date: Tuesday, November 15, 2016 at 9:57 PM To: LISP mailing list list > Cc: "lisp-chairs@ietf.org" > Subject: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis Folks, The chairs received a request for the following document to be adopted as a WG item: https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ Here starts a 14 day call for adoption, this call will end on Wednesday the 30 November, 2016. Please email the WG list stating whether or not you support acceptance. If you email to support the acceptance of this document as a WG item, pleas= e also indicate if you are able and willing to either contribute to, or revie= w, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. The Chairs Joel & Luigi --_000_D45259D81F3E5Arrahmanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support.

From: lisp <lisp-bounces@ietf.org> on behalf of Luigi Ianno= ne <ggx@gigix.net>
Date: Tuesday, November 15, 2016 at= 9:57 PM
To: LISP mailing list list <lisp@ietf.org>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
Subject: [lisp] Call for adoption d= raft-farinacci-lisp-rfc6830bis

Folks,

The chairs received a request for the following document to= be
adopted as a WG item:

https://data= tracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/

Here starts a 14 day call for adoption, this call will end = on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, pleas= e
also indicate if you are able and willing to either contribute to, or = review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.=


The Chairs
Joel & Luigi
 --_000_D45259D81F3E5Arrahmanciscocom_-- From nobody Wed Nov 16 17:39:22 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D8C1294CC; Wed, 16 Nov 2016 17:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbEYfsq6B9sK; Wed, 16 Nov 2016 17:39:19 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D4F1294A6; Wed, 16 Nov 2016 17:39:19 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id n6so120668939qtd.1; Wed, 16 Nov 2016 17:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IXdPQQdz83zdwpOMjk5HyvT++E0rvw1KNfatrx3jJ3E=; b=gW4XFs8ZhE7w1usP0UKr25XBLpgs8X91mecgnMltEgUrj00+bg+OCBqJutMiW5zEOi wSPLxC78GGmHaQ2T4ePcXFqmP5x4cWNAHSZOzvs7z60LIxxOxV3XG65XoM2MIkk9c1Lo Dw4cBOkWg+zZabGdMJZ0PWzVLpjBGUq66rSNLhNd1Zwe2hpJfYZsYrgikAglKIRlKG2L bVoBFWMIQ7sIAbOSO/4ECJQBEWJYfXhPuw0K8LYMNZb+2Mk9H0uvvCh24Zhi3E49HcEa f2dXAkCV98G7iARiJfurlL08aI0wS1SVcrNqvRyYAwCm+x0/twTHYJrDNkhK8b+oHPuK 8bxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IXdPQQdz83zdwpOMjk5HyvT++E0rvw1KNfatrx3jJ3E=; b=lvW8hnB+vNnFIiVjWEppERAcKVtWZI9kzxbFOwEsDwg70VoUq/jG01dhojQg59dm2M mNrOjMkzXDaKYtHuSBUn3+4K6GYmURgadpzmJfR6DHXYjYxn201AHXYfh2u32Ee9d1jS 0e/OPHHpM7WLc0OMhilD+hlt1RtGWAbqUXMGlXRD70wCyPR4LyJhuwYV2xFaIrlidWaR pbAEG01tDBBoOSWkEOdy7+lX3Ny+wHnxGmlqPbQrPhlM8S3PWcnUt3IHZeIGnV9PKI+s q9YRfs+uDeBtJDmEQaLPyovTXw20Tr7tqkP5rDOSPCDh8w79YXvcIluJr7G9RDUJhlkP tiIA== X-Gm-Message-State: AKaTC03x7ueb/hyXOqRLrzaubKASs0yyizVXqhFMlpTinqSWdpWvB6ROVVBg+Tn0RKCGkMjH+o4hISd0tI4mvw== X-Received: by 10.200.48.100 with SMTP id g33mr302427qte.249.1479346758247; Wed, 16 Nov 2016 17:39:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.78 with HTTP; Wed, 16 Nov 2016 17:39:17 -0800 (PST) In-Reply-To: References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> From: Padma Pillay-Esnault Date: Thu, 17 Nov 2016 10:39:17 +0900 Message-ID: To: "Reshad Rahman (rrahman)" Content-Type: multipart/alternative; boundary=001a1143b2a6066e2f054175428c Archived-At: Cc: "lisp-chairs@ietf.org" , LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:39:21 -0000 --001a1143b2a6066e2f054175428c Content-Type: text/plain; charset=UTF-8 Support adoption and willing to review Regards Padma On Thu, Nov 17, 2016 at 8:45 AM, Reshad Rahman (rrahman) wrote: > I support adoption. I am willing to contribute or review. > > Regards, > Reshad. > > From: lisp on behalf of Luigi Iannone < > ggx@gigix.net> > Date: Tuesday, November 15, 2016 at 9:58 PM > To: LISP mailing list list > Cc: "lisp-chairs@ietf.org" > Subject: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis > > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > *https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ > * > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, > please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > > The Chairs > Joel & Luigi > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > > --001a1143b2a6066e2f054175428c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support adoption and willing to review

= Regards
Padma

On Thu, Nov 17, 2016 at 8:45 AM, Reshad Rahman (rrahman) = <rrahman@cisco.com> wrote:
I support adoption. I am willing to contribute or review.

Regards,
Reshad.

From: lisp <lisp-bounces@ietf.org> on beh= alf of Luigi Iannone <ggx@gigix.net>
Date: Tuesday, November 15, 2016 at= 9:58 PM
To: LISP mailing list list <lisp@ietf.org>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org= >
Subject: [lisp] Call for adoption d= raft-farinacci-lisp-rfc6833bis

Folks,

The chairs received a request for the following document to be
adopted as a WG item:

https://datatracker.ietf.or= g/doc/draft-farinacci-lisp-rfc6833bis/

Here starts a 14 day call for adoption, this call will end on
Wednesday the 30 November, 2016.

Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, pleas= e
also indicate if you are able and willing to either contribute to, or=C2=A0= review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.=


The Chairs
Joel & Luigi

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


--001a1143b2a6066e2f054175428c-- From nobody Wed Nov 16 19:15:38 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4612956F; Wed, 16 Nov 2016 19:15:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147935253738.23862.3751900775592562135.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2016 19:15:37 -0800 Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, lisp@ietf.org Subject: [lisp] Alexey Melnikov's No Objection on draft-ietf-lisp-lcaf-20: (with COMMENT) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 03:15:37 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-lisp-lcaf-20: No Objection 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-lcaf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- DNS names and URIs need normative references. AS per discussion with Dino: Adding an informative reference to use case document(s) in the Introduction Section and examples of URIs and JSON types would help a reader unfamiliar with LCAF to better understand the need for these types. From nobody Wed Nov 16 19:44:02 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AD912963C for ; Wed, 16 Nov 2016 19:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuW3sgA_F6T9 for ; Wed, 16 Nov 2016 19:43:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B65129706 for ; Wed, 16 Nov 2016 19:43:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CVI59421; Thu, 17 Nov 2016 03:43:52 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Nov 2016 03:43:51 +0000 Received: from DFWEML501-MBS.china.huawei.com ([10.193.5.222]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Wed, 16 Nov 2016 19:43:46 -0800 From: Richard Li To: "lisp@ietf.org" Thread-Topic: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis Thread-Index: AQHSP7VKlDj1rFxXNkOjOKi4SrBkF6Db0E8AgAC5dZA= Date: Thu, 17 Nov 2016 03:43:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.104.139] Content-Type: multipart/alternative; boundary="_000_F061CEB6876F904F8EA6D6B92877731C3A5120AFdfweml501mbs_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.582D2779.0011, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 861f640ed24a0dcbbed83afa8f2e4446 Archived-At: Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 03:44:01 -0000 --_000_F061CEB6876F904F8EA6D6B92877731C3A5120AFdfweml501mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. And I will be happy to review it. Thanks, Richard On 11/16/16 11:57 AM, Luigi Iannone wrote: Folks, The chairs received a request for the following document to be adopted as a WG item: https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ Here starts a 14 day call for adoption, this call will end on Wednesday the 30 November, 2016. Please email the WG list stating whether or not you support acceptance. If you email to support the acceptance of this document as a WG item, pleas= e also indicate if you are able and willing to either contribute to, or revie= w, (or both) the draft. Sitting in silence does not indicate support, please respond appropriately. The Chairs Joel & Luigi _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --_000_F061CEB6876F904F8EA6D6B92877731C3A5120AFdfweml501mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support. And I will be ha= ppy to review it.

 <= /p>

Thanks,=

 <= /p>

Richard=

 <= /p>



On 11/16/16 11:57 AM, Luigi Iannone wrote:

Folks,

 

The chairs received a req= uest for the following document to be
adopted as a WG item:

https://datatracker.ietf.org/doc/draft-= farinacci-lisp-rfc6830bis/

 

Here starts a 14 day call= for adoption, this call will end on
Wednesday the 30 November, 2016.


Please email the WG list stating whether or not you support acceptance.

If you email to support the acceptance of this document as a WG item, pleas= e
also indicate if you are able and willing to either contribute to, or = review, (or both) the draft.

Sitting in silence does not indicate support, please respond appropriately.=

 

The Chairs

Joel & Luigi




___________________________________________=
____
lisp mailing list
lisp@ietf.=
org
https://www.ietf.org/mailman/listinfo/lisp

 

--_000_F061CEB6876F904F8EA6D6B92877731C3A5120AFdfweml501mbs_-- From nobody Wed Nov 16 19:47:00 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0F512957F; Wed, 16 Nov 2016 19:46:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147935441517.23855.13301257008802596161.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2016 19:46:55 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lcaf-21.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 03:46:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol of the IETF. Title : LISP Canonical Address Format (LCAF) Authors : Dino Farinacci Dave Meyer Job Snijders Filename : draft-ietf-lisp-lcaf-21.txt Pages : 44 Date : 2016-11-16 Abstract: This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-lcaf-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-lcaf-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 17 00:36:51 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006D212970A for ; Thu, 17 Nov 2016 00:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2szSiuW6gvn for ; Thu, 17 Nov 2016 00:36:48 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E681296B7 for ; Thu, 17 Nov 2016 00:36:48 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 3so17054862pgd.0 for ; Thu, 17 Nov 2016 00:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=QP1uGzBmLsL9r6k1j9YD3IUeCjZeZTgMQsHIfTvjV4Y=; b=hGyJyKgfyFcBX2TXxI/tNBld8KlIC+9BpGHT3qr+ydwI3/LjZCdfNbd9i2TSibNouQ HNlHYpv+cAhJuABPKAvkBV68DFEW0BvXo9UqkZNn/+ukGgmCYAR4ISOIWkrhiDM/4Im8 gYQqsW+ifu7FqjMk/4OVQbqIp6sbO1b7+9ZB/gQfSfNeC5xQSh3d+OBgv280JSfWCXSD meQkJqKDLUwrhN9/7ZyRp118BDVyLAFoSuQ0u7vl6uXDQrHUpz+4Q3g9eHyAC4jYIBx+ Yb7m+Q9uJc3VOKLepmuHF+Sd0Nto1c4mUgTldCOsFkU6RChGNy34HFviCCcaEt6cpdkY Jd1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=QP1uGzBmLsL9r6k1j9YD3IUeCjZeZTgMQsHIfTvjV4Y=; b=i40YQ49waAtZdZTb9g5jPBWjj+1qzJdsPDoHGt3FRWo46/zk4reZMkJY6fJSsQxy6N kFV6yb987kaTOHDmH2IKOkXR4xm4O35WltJMGqKwKLphA+vcUET/VG4foUTxqVcKdYVo 3MZh5ZuQX5czUx0KeEwHGieQmRaLv5cpo19ZVYauh13vK9R/XCY02ywH5jhW4Xwfp2lK 4JaEtvoYnkqmNIOUgsevWplA0Cqf4CdEr3fMdER9Xr5ouUR/jyKyX44j+GGVjubrIYCw MS2gLSTEGhTSRgNR21nfmEjPA/O+7xau64lpZQnQzQVHtVmC7m/7Ry4hxVRKwCtfP4qI 71TA== X-Gm-Message-State: ABUngveBZj3mXm/geFvV2OWvq8uOoUR2W9PuwtvA0ypitGw8XiLpLyca+D4J9s/Yk7O+8g== X-Received: by 10.99.122.14 with SMTP id v14mr5133931pgc.31.1479371808086; Thu, 17 Nov 2016 00:36:48 -0800 (PST) Received: from t2001067c0370012804a301e64da3d53e.v6.meeting.ietf.org ([2001:67c:370:128:4a3:1e6:4da3:d53e]) by smtp.gmail.com with ESMTPSA id b64sm4460509pfc.74.2016.11.17.00.36.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 00:36:47 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_7829A06D-A309-4E76-93B2-C135B7719162" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <4F0F4D9C-DEB1-485E-951C-553F42223C96@gigix.net> Date: Thu, 17 Nov 2016 09:36:48 +0100 To: LISP mailing list list X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org Subject: [lisp] WG Last Call for draft-ietf-lisp-sec-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:36:50 -0000 --Apple-Mail=_7829A06D-A309-4E76-93B2-C135B7719162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, The authors of the LISP-Security (LISP-SEC) document = [https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ = ] asked for WG = Last Call.=20 This email starts the usual two weeks WG Last Call, to end December = 1st, 2016. Please review this WG document and let the WG know if you agree that it = is ready for handing to the AD. If you have objections, please state your reasons why, and explain what = it would take to address your concerns. Thanks Luigi & Joel= --Apple-Mail=_7829A06D-A309-4E76-93B2-C135B7719162 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

The authors of the LISP-Security = (LISP-SEC) document [https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/] = asked for WG Last Call. 

This email starts the usual two weeks = WG Last Call, to end December  1st, 2016.

Please review this WG = document and let the WG know if you agree that it is ready for handing = to the AD.
If you have objections, please = state your reasons why, and explain what it would take to address your = concerns.

Thanks

Luigi & = Joel
= --Apple-Mail=_7829A06D-A309-4E76-93B2-C135B7719162-- From nobody Thu Nov 17 00:39:58 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4053C12960C; Thu, 17 Nov 2016 00:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi2ryluhhH6I; Thu, 17 Nov 2016 00:39:54 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3741294F7; Thu, 17 Nov 2016 00:39:54 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 189so48401490pfz.3; Thu, 17 Nov 2016 00:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C24wpDkli7MvBNYt0rf3vM+QpHKqwRP1XJSzzou/6bg=; b=dqdBLWueKqhEL8hMXUYjt6rddfqVpjleXIfJsB2GwQID1SxqEUMwKk+XrqQ2D1cn4q nwliMTS5mQrZ0HYNWKfl2Gi7Q+r7eolwfgPiYx1noIc7zCuEOebBexl4PU3IEidR7RE3 j+KFDpM9dCClxQaXWVOBfF6I1hX0Ppk0XoyVrcI50fDjseh3GJzwzjgWsBGaG0ILQSEr jKf9BvwuYCIScNnEbukuefv2xgwN6kjmOpQvluey4yTBdK1FhesMLh8tZYDrRnJEMrur kv6rya1lFwSO26Qd0U+3ltGEa44bwz+197v8ClFzomqfw7ymyq3FxEPb9Wx/cGSUBLdz g5Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C24wpDkli7MvBNYt0rf3vM+QpHKqwRP1XJSzzou/6bg=; b=gFswp3i8QWCpPz9JEKY6GEt5udY17g+MOBnf+kaMVw/BW9Jkz1CxZGiUP1UHRDXjjM QaGymdT4zR2C3acMhe2m4EoGpBu4dhKApZevMXVuuV6fpSG6LH5lI1gBXIDPRkNfON8N cJVnY276Bua17qvp0n/3vctBy0fFXJPVtd7s9xp9qy/n9ZbPOGEQHJGS5H5WKfAgz9dI 6gx9iXNw4RUL6KzVXtsrwNt1k0oajCenA3AeH6WnfCyB0leIrwVheM4lPcjNZ5MvvElI lNtFbY8pj1c6jpO7YGRWOcKURqH2XZz1hSv184STDapf8JxJPfblNCgKgS1CtThLL95E ilqg== X-Gm-Message-State: ABUngvd4i9xJjBd0c5lAXObpnFHPhiWXxgX/iJeiJZ7FD6YeCwSJc8fBAg/pn/DKLYxOnw== X-Received: by 10.98.93.201 with SMTP id n70mr3083286pfj.161.1479371993749; Thu, 17 Nov 2016 00:39:53 -0800 (PST) Received: from t2001067c037001441c3a3d6e7af30294.hotel-wired.v6.meeting.ietf.org ([2001:67c:370:144:1c3a:3d6e:7af3:294]) by smtp.gmail.com with ESMTPSA id y2sm4486992pff.82.2016.11.17.00.39.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 00:39:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <4F0F4D9C-DEB1-485E-951C-553F42223C96@gigix.net> Date: Thu, 17 Nov 2016 00:39:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F0F4D9C-DEB1-485E-951C-553F42223C96@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-sec-12.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 08:39:56 -0000 I think the document is ready. Dino > On Nov 17, 2016, at 12:36 AM, Luigi Iannone wrote: >=20 > Hi All, >=20 > The authors of the LISP-Security (LISP-SEC) document = [https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/] asked for WG = Last Call.=20 >=20 > This email starts the usual two weeks WG Last Call, to end December = 1st, 2016. >=20 > Please review this WG document and let the WG know if you agree that = it is ready for handing to the AD. > If you have objections, please state your reasons why, and explain = what it would take to address your concerns. >=20 > Thanks >=20 > Luigi & Joel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Thu Nov 17 07:05:33 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C5A129583; Thu, 17 Nov 2016 07:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7E0gLF1JbVZ; Thu, 17 Nov 2016 07:05:29 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9A129976; Thu, 17 Nov 2016 07:05:26 -0800 (PST) Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id uAHF5OlT018051; Thu, 17 Nov 2016 16:05:24 +0100 Received: from [0.0.0.0] (unknown [173.38.220.36]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id 0AF2C418; Thu, 17 Nov 2016 16:05:23 +0100 (CET) To: Luigi Iannone , LISP mailing list list References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> From: Lori Jakab Organization: LISPmob Message-ID: Date: Thu, 17 Nov 2016 17:05:22 +0200 MIME-Version: 1.0 In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp-chairs@ietf.org Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 15:05:31 -0000 I support this document becoming a WG item. -Lori On 11/16/16 4:58 AM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > _https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/_ > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > > The Chairs > Joel & Luigi > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Nov 17 07:09:13 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393411295C0; Thu, 17 Nov 2016 07:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQVCQm1m-FZa; Thu, 17 Nov 2016 07:09:06 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3A612945C; Thu, 17 Nov 2016 07:09:06 -0800 (PST) Received: from gw-2.ac.upc.es (gw-2.ac.upc.es [147.83.30.8]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id uAHF95rO018179; Thu, 17 Nov 2016 16:09:05 +0100 Received: from [0.0.0.0] (unknown [173.38.220.36]) by gw-2.ac.upc.es (Postfix) with ESMTPSA id 0EE27140; Thu, 17 Nov 2016 16:09:04 +0100 (CET) To: Luigi Iannone , LISP mailing list list References: From: Lori Jakab Organization: LISPmob Message-ID: <2dcc0e2f-1b4d-dca2-e2f6-d43e29676f99@lispmob.org> Date: Thu, 17 Nov 2016 17:09:03 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: lisp-chairs@ietf.org Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 15:09:12 -0000 I support this document becoming a WG item. -Lori On 11/16/16 4:57 AM, Luigi Iannone wrote: > Folks, > > The chairs received a request for the following document to be > adopted as a WG item: > > _https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/_ > > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. > > Please email the WG list stating whether or not you support acceptance. > > If you email to support the acceptance of this document as a WG item, please > also indicate if you are able and willing to either contribute to, > or review, (or both) the draft. > > Sitting in silence does not indicate support, please respond appropriately. > > > The Chairs > Joel & Luigi > > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From nobody Thu Nov 17 09:31:10 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEA51299B0; Thu, 17 Nov 2016 09:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyxjC2NK2bju; Thu, 17 Nov 2016 09:31:06 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4FA1299A2; Thu, 17 Nov 2016 09:31:06 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id d2so50283049pfd.0; Thu, 17 Nov 2016 09:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=r0gYaTuvI6a12FamgJQ1DCubbWd1v2RybEYpcP9xMHA=; b=jE6EXRF/rHl4kkAnb7KaXvQLw9Y1/AlIXMnRUe6fvWxL3m+TeTlrPWzenhJ/lCHb78 l4X6M0Jo6XtqZxh+QvocbEuQmf9BHbTQH8H1poChU0AGcuUJPw+aNDapNYXfsWoJ+YMv h2eF+J4xPowdLS++VeyTahXJ+9KBcMA0pexxTgo8Pajt1p1ZEn2NMvrapmstyr7bVc6X a9YKTT5Gw3ESFMvIXS4vZPk3Ua+SHuJEQ3F4Dk/AfzkU1Q9+W6+D3GbroVpi3m6e2IX7 X3AoRvyUrAjf6XdrAdy6gkWOmtNR93Xak2Kc5g/Ev1npKIbY9T9L0ApVE/SBux6wHGQn B2XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=r0gYaTuvI6a12FamgJQ1DCubbWd1v2RybEYpcP9xMHA=; b=Ij9TLVaWTVVHoP2PFSReVMk5nkVPDgCmoQPMWZOJAvny2UZUuE1Y70t/DoY2Ha7GQj 9yowdz3jZ0BCHDJOk91zrIF5Q+u+nVs6/wwiQVX9Dul4BLKcXgEjkpxiah7lSsJXrm12 rmzs8hwly5c9p+xH7s8MSoc/nVSbnP6XyOsQovR6dBYvvJMYulWu0m1Lw6W7PssS1gJe gl3HS3V9T6qxtTBQRxii6yCuy8iJdBA/eRhzskFPmWhUdjwTqH39kQ4SCHvthxLlPe+C h7IG1Z6iYlK8RpcNTo7CvdCsVoaTT5ruc41tTOrfI7cpLDETrFo1XMn0dC8+WOSpZBXJ rIUg== X-Gm-Message-State: ABUngvfXpNpDIYBn1NXeEyBInH/LSO8mnHZu0APwQF8Iqnx7ZvIFz0P6RJEqXXJlVi6DcA== X-Received: by 10.98.155.146 with SMTP id e18mr6265952pfk.45.1479403866371; Thu, 17 Nov 2016 09:31:06 -0800 (PST) Received: from ?IPv6:2001:420:30e:1250:e136:fe33:bbc1:7556? ([2001:420:30e:1250:e136:fe33:bbc1:7556]) by smtp.gmail.com with ESMTPSA id s8sm9592827pfj.45.2016.11.17.09.31.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 09:31:05 -0800 (PST) From: Florin Coras Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E5FE44EE-993B-451A-8B70-0DB380EB5265" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 17 Nov 2016 09:31:05 -0800 In-Reply-To: To: Luigi Iannone References: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6830bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 17:31:08 -0000 --Apple-Mail=_E5FE44EE-993B-451A-8B70-0DB380EB5265 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adopting this document as WG item. Florin > On Nov 15, 2016, at 6:57 PM, Luigi Iannone wrote: >=20 > Folks, >=20 > The chairs received a request for the following document to be > adopted as a WG item: >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bis/ = >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. >=20 > Please email the WG list stating whether or not you support = acceptance. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond = appropriately. >=20 >=20 > The Chairs > Joel & Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_E5FE44EE-993B-451A-8B70-0DB380EB5265 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I support adopting this document as WG item.
Florin

On = Nov 15, 2016, at 6:57 PM, Luigi Iannone <ggx@gigix.net> = wrote:

Folks,

The chairs received a = request for the following document to be
adopted as a WG = item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6830bi= s/

Here starts a 14 day call for adoption, this call will end = on
Wednesday the 30 November, 2016.
Please email the WG list stating whether or not you support = acceptance.

If you email to support the = acceptance of this document as a WG item, please
also = indicate if you are able and willing to either contribute to, = or review, (or both) the draft.

Sitting = in silence does not indicate support, please respond appropriately.


The Chairs
Joel & = Luigi
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

= --Apple-Mail=_E5FE44EE-993B-451A-8B70-0DB380EB5265-- From nobody Thu Nov 17 09:32:04 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDBA1299B7; Thu, 17 Nov 2016 09:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij_FuzsN0UTf; Thu, 17 Nov 2016 09:32:01 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4741299B5; Thu, 17 Nov 2016 09:32:01 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id i88so50066653pfk.2; Thu, 17 Nov 2016 09:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vICNHUMKbJ673KZYPBkkxo0noQnXV/SnrwoFOyZa+Kk=; b=MRorqeHK62SlIbSeaOMLoRbidN/8DB+BEn61sXRPBbdqQ+rfvg2NhHMtZc+gR987Ml 7FxHQLQxGicZePRw1UlXnEL9nJMrxNYXcEPwWcHsJdypIRJCb0kctcHpSSOfgYfPBT8N g6CDnbbx+Ck7OJok04H3HWfBGy3vt3fF7DJKvy+vtAPWJGgLmbhdBsEHDGdjDexz8e5j dpGce92hXpW3sjn6jYS1JSV+6B0zLhRhDE5q9FbRkQZ2Y03ji+fFbdm5NBEFGCkN7I0D Y5ihqlKS7jmIX77z6Ml5iUBmCudBqcxIsySXG6Ao3MKHYWIodktYBLzYXEuOaQeu7tZS ryaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vICNHUMKbJ673KZYPBkkxo0noQnXV/SnrwoFOyZa+Kk=; b=R8jWLwSoTTEBU5MfRDW5FEP/SW9q5ItuUafjr4V45y6OTl024P5MPAJvV+n3T3b33D 0pk+K96spqKfv6xRrXIA8UKRlL02KDKng8AqUWXc/8Q7zQy2Uo5iebvKef8AWki7mHby YoBDFoHWfk4mu4fpNDE3HU2t23zZ+fId9FmV6L5X8h89h+9hhenuT5ShB5fSv3f7pvZf jd6xiEuvpTc0N0qHcCAdmeiBGJ4N9WV5e3zaAcX8FeAiyer62TV0nxYKR6C4UCgBzPKV 6TWEHb8W9C3uoSYsjzySLjRvy1DrSXp2Iah+lKW0HRsNBoZOkhY4XxxW/hdAHkChw0Fh OP6Q== X-Gm-Message-State: ABUngveCYWZ1yv0VvKEfE3PiAHQMNnq1QcDHVgISOTdXR9ZeM226RmJKpQ6uxnXJ1gPgcA== X-Received: by 10.99.171.65 with SMTP id k1mr9820659pgp.87.1479403921154; Thu, 17 Nov 2016 09:32:01 -0800 (PST) Received: from ?IPv6:2001:420:30e:1250:e136:fe33:bbc1:7556? ([2001:420:30e:1250:e136:fe33:bbc1:7556]) by smtp.gmail.com with ESMTPSA id s8sm9592827pfj.45.2016.11.17.09.32.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 09:32:00 -0800 (PST) From: Florin Coras Message-Id: <8A48064D-BB10-4E64-AAC7-369FDDC2FA0A@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_943EAAF1-0581-44E0-9FF6-32F3DFF4CB3E" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 17 Nov 2016 09:32:00 -0800 In-Reply-To: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> To: Luigi Iannone References: <653192D8-E2DD-4741-9882-BBA8ADB8F6C7@gigix.net> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, LISP mailing list list Subject: Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 17:32:03 -0000 --Apple-Mail=_943EAAF1-0581-44E0-9FF6-32F3DFF4CB3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adopting this as a WG item. Florin > On Nov 15, 2016, at 6:58 PM, Luigi Iannone wrote: >=20 > Folks, >=20 > The chairs received a request for the following document to be > adopted as a WG item: >=20 > https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/ = >=20 > Here starts a 14 day call for adoption, this call will end on > Wednesday the 30 November, 2016. >=20 > Please email the WG list stating whether or not you support = acceptance. >=20 > If you email to support the acceptance of this document as a WG item, = please > also indicate if you are able and willing to either contribute to, or = review, (or both) the draft. >=20 > Sitting in silence does not indicate support, please respond = appropriately. >=20 >=20 > The Chairs > Joel & Luigi > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_943EAAF1-0581-44E0-9FF6-32F3DFF4CB3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I support adopting this as a WG item.

Florin

On = Nov 15, 2016, at 6:58 PM, Luigi Iannone <ggx@gigix.net> = wrote:

Folks,

The chairs received a = request for the following document to be
adopted as a WG = item:

https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bi= s/

Here starts a 14 day call for adoption, this call will end = on
Wednesday the 30 November, 2016.
Please email the WG list stating whether or not you support = acceptance.

If you email to support the = acceptance of this document as a WG item, please
also = indicate if you are able and willing to either contribute to, = or review, (or both) the draft.

Sitting = in silence does not indicate support, please respond appropriately.


The Chairs
Joel & = Luigi
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

= --Apple-Mail=_943EAAF1-0581-44E0-9FF6-32F3DFF4CB3E-- From nobody Mon Nov 21 14:49:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7A1293E4; Mon, 21 Nov 2016 14:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_WhKRFb0IOO; Mon, 21 Nov 2016 14:49:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E197E1294B6; Mon, 21 Nov 2016 14:49:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08FBCBE39; Mon, 21 Nov 2016 22:49:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOCOR3hnoKqu; Mon, 21 Nov 2016 22:49:22 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54553BE38; Mon, 21 Nov 2016 22:49:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1479768562; bh=dR3QyX02xXuox2f+rzI+rSC+ae7Gf++gsWt7Q+5gMWI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=EsedmCNuIjxz+VTGrB/isCSOGtpdiXgOs4zo1F2DjPL6i1VxdbNAablJ3BGtJmhJL za6dcdRw+GEuyOpzWCCS6J4Exy7nMrbIUcySm7d7RH8Eg8lxVehtLRJY0z5Mmfg/4s E5T8MHWmWCe6iWqst5UoThvpH6b0sWd7gzlnuOe8= To: Dino Farinacci References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5b931a61-0c74-7045-ab1e-f240d762bde3@cs.tcd.ie> Date: Mon, 21 Nov 2016 22:49:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090009090507000508000100" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, LISP mailing list list , The IESG Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 22:49:30 -0000 This is a cryptographically signed message in MIME format. --------------ms090009090507000508000100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dino, On 08/11/16 16:42, Dino Farinacci wrote: >> Hi Dino, >>=20 >> Apologies for the slow response... >>=20 >> I checked the diff from -17 to -20 before replying. >=20 > Great, thanks. Please ack based on if you agree with my responses > below. I didn=E2=80=99t see anything you said where I need another upda= te. > But want your agreement first. Hmm. I don't think I agree about another update not being needed at all. >=20 >>> [RFC6830] states RLOC records are sorted when encoded in control >>> messages so the locator-set has consistent order across all xTRs >>> for a given EID. The sort order is based on sort-key {afi, RLOC- >>> address}. When an RLOC is LCAF encoded, the sort-key is {afi, >>> LCAF- Type}. Therefore, when a locator-set has a mix of AFI >>> records and LCAF records, they are ordered from smallest to >>> largest AFI value. >>=20 >> Sorry I'm not getting that. When I read "canonical" I take that to >> mean that anyone given the items in any order can re-construct the >> same set of octets. Are you defining some other format that doesn't >> amount what I perceive as being a canonical form? (For background, >> most canonicalisation that turns up in security relates to >> signature/MAC inputs where you need to produce the exact same set >> of bits.) >=20 > The ordering is for the sole purpose of using reachability bits that > are consistent among multiple ETRs that are registering the same RLOC > set. Here is an example. Say we have two ETRs for a LISP site, their > RLOCs are ETR1 and ETR2 and they are both registering an EID-prefix, > we want the mapping to be: >=20 > EID-prefix -> {ETR1, ETR2} >=20 > And we want ETR1 to register the above mapping in the same order as > ETR2. So we when the RLOC reachability bits are set for this RLOC-set > (say 0x3), we know the low-order bit means we are advertisting the > reachability-bit for ETR1, and the 0x2 bit is for ETR2. >=20 > That is why we have a sort order. This is discussed in detail in > RFC6830, and we are just waying here that if the RLOCs are > accompanying with other data, that is defined by a specific LCAF > encoding that the RLOC address are sorted. >=20 >> If you don't need what I'd call a canonical form then maybe calling >> it something else might be good, or explaining that you're using >> that term differently from the normal crypto usage. >=20 > We are using it from an =E2=80=9Caddress=E2=80=9D perspective. Has noth= ing to do with > security. ;-) >=20 >> If you do need (what I'd call) a canonical form, then I think more >> work is still needed. (And that's tricky for URIs as there is no >> general canonicalisation for those.) >=20 > It is a canonical form for all new types of addresses or information > we want to add in the future. So maybe I'm being thick but I still don't see how one reliably orders things when the values are URIs that have paths with varying case, e.g. URI1=3D"https://example.com/Foo/" and URI2=3D"https://Example.com:443/foo". Can you explain how one ensures that all encoders produce the same order for the above or that it doesn't matter or that one never hits that case with two URIs being put in order? >=20 >>=20 >>>=20 >>>> - 4.3: I agree with Ben's comment. You ought include some text >>>> here to the effect that this information can be privacy=20 >>>> senseitive and to recommend not sending or storing it in such=20 >>>> cases. >>>=20 >>> I did that for the next revision. >>=20 >> I don't see the recommendation to not use/send/store this unless >> needed nor anything other than a generic warning to go read BCP160, >> which I'm not at all sure is something that would help LISP >> implementers. Do you really think they'll buy into the geopriv >> architecture? I don't really. >>=20 >> I'd argue that it'd be better to explain the issues here and to >> recommend to avoid the pitfalls we know exist. >=20 > It is here (page 35-36 in -20): I don't see that in -21. I see text saying "there might be some privacy issues... maybe." The discuss point asked that it state that this information can be privacy sensitive and hence ought not be sent or stored unless it's needed. I also don't recall an argument that that kind of text would be wrong. >=20 > 6. Security Considerations >=20 > There are no security considerations for this specification. The=20 > security considerations are documented for the protocols that use=20 > LISP Canonical Addressing. >=20 > The use of the Geo-Coordinates LCAF Type may raise physical privacy=20 > issues. Care should be taken when configuring the mapping system to=20 > use specific policy parameters so geo-location information is not=20 > returned gratuitously. It is recommended that any documents that=20 > specify the use of the Geo-Coordinates LCAF Type should consider the=20 > applicability of the BCP160 [RFC6280] for location-based privacy=20 > protection. >=20 >>=20 >>>> - 4.4: there are also potential privacy issues here if this >>>> could be used to identify traffic that is from one specific >>>> host behind a NAT. A similar privacy warning should be >>>> included. >>>=20 >>> It does not identify any host. >>=20 >> Are there no LISP use-cases where the Private ETR RLOC Address or=20 >> RTR RLOC Address could map to a host behind a NAT e.g. in my home? >=20 > Yes, kinda. But there is no need for the private-RLOC right now and > we are working that out in the NAT-traversal individual submission > draft. >=20 >> If there are (and there seem to be many LISP use-cases:-) then=20 >> maybe this warning is needed. But if not, yes, it'd not be needed.=20 >> Can you clarify? >=20 > We don=E2=80=99t know how ot clarify yet. We can in the future. Why can't you fix this now? Why can't you say to not use this in any cases that might be privacy sensitive and give the example of exposing information about specific hosts behind a NAT as an example? I don't see why it's better to ignore problems like that, as we do know that when we ignore such things, they do come back to bite us in the ass later. >=20 >>=20 >>>> - 4.7: Sorry, when is key material sent in a message? How is >>>> that protected? (Key ids are fine, but not key values) >>>=20 >>> That is documented in the two use-case references. >>=20 >> So for DDT, those are always public keys, right? And are part of >> some PKI or equivalent. If so, those are fine. >=20 > They are public keys and DDT, itself can be regarded as a PKI. But > each parent transmit the public-key of the children it is referring. > So it=E2=80=99s not a table lookup mechanism but an on-demand push. >=20 >> But for lisp-crypto, if this can be a long term symmetric key, or a >> derived shared secret then more needs to be said >=20 > LISP-DDT-SEC is control-plane security, and lisp-crypto is data-plane > security. They are not related and don=E2=80=99t depend on each other=E2= =80=99s > functionality. >=20 >> I think. Or at least, we need the argument that storing such keys >> is safe. Can you provide that? I don't recall >=20 > We don=E2=80=99t store keys for lisp-crypto. We store public-keys for > LISP-DDT. >=20 >> seeing that go by in the discussion of lisp-crypto but I may be >> forgetting. >=20 > So are you good with my response? I just had a look back at lisp-crypto and it seems I was remembering wrong and that doesn't support symmetric keys. Assuming I've not gotten that wrong again, this one is good:-) >=20 >>=20 >>>=20 >>>> - 4.10.2: The same privacy issues apply here as for 4.3 and >>>> 4.4, if the MAC address maps to e.g. a portable device carried >>>> by a person. >>>=20 >>> In this case, the MAC address can be a host/person. I put a >>> refernece to the Security Considersations section that >>> references RFC6280/BCP160. >>=20 >> See above WRT BCP160. I'm really not sure it's a great reference >> here, in terms of being useful to implementers. >=20 > See Security Considerations section. I did. That text didn't help. Just referring to BCP160 is not good enough here IMO, you need some text to call out the actual issue, which is not called out clearly in that BCP, which deals with complex location issues in a pretty complex manner that is not IMO likely to be useful to LISP implementers. >=20 >>=20 >>>> - 4.10.3 and all of section 5: What are these for? I don't see >>>> the sense in defining these if there is no well defined way to >>>> use them. Any of these might have undesirable security and/or >>>> privacy characteristics. >>>=20 >>> We have use-cases for them. And they are being documented in >>> both other working group and individual contributed drafts. >>=20 >> Yeah but this seems like throwing the kitchen-sink and all at the >> mapping system, which seems to me to be a recipe for security and >> privacy failures. With the level of detail now available, how could >> we know for sure if I'm right or not? Wouldn't it be better to >> define these as they are needed and as they are better understood >> from the security/privacy POV? >=20 > They are needed and we are experimenting with them now. We can apply > updates when we learn more. We still do rough concensus and running > code. ;-) If more than one person writes code then they won't interop based on this low quality text. Running code does not mean it's ok to just sketch out definitions of data structures. IMO almost all of section 5 would be better deleted from this until good specification text exists. I don't see a way to resolve this point. If the WG insist on including types for badly defined structures then I'll just end up as an abstain on this. Can the chairs or AD confirm that the WG really have consensus to include all of the stuff in section 5 at this level of (missing) detail? Thanks, S >=20 > Dino >=20 --------------ms090009090507000508000100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjEy MjQ5MjJaMC8GCSqGSIb3DQEJBDEiBCBciQaSr35f7XVXWl09TUoYSBHPJpUSnXHgaJsRf7tJ PTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCtvszCzn3UNXsP+6dwHyDBBm2K9tlcdGkmKgpEfP7rb4HaURSGoiE6 mTm1wQ3gMmMc5Y6uqbNyX6Uhb41lW2aW8tIq4XmmP/keIeyHbb4LMEgNlME5votFznDCJQl9 hLC4+XGKyPoY61K7cxOncq+4BFZzkHvniN59NkjWzJYxKCi/LPvGB+cvUWO/TbwBYlTuHhGu WX0bV97YA8jdOf9guTi4nKCaoxPQSVe+QrFRIleqiNmMvr1xtcAb4KuMFLc/RTy5U8CPVOiY LknjTBNECLH1X2ddLiWWmRcJ2hxzljptgx5KAFb6ok9WWIKMlhCZJBkyyGbkJK+bulTa0o3i AAAAAAAA --------------ms090009090507000508000100-- From nobody Mon Nov 21 15:50:39 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8B129502; Mon, 21 Nov 2016 15:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6gDNedylWQX; Mon, 21 Nov 2016 15:50:26 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C5A1294B0; Mon, 21 Nov 2016 15:50:25 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id x23so137906pgx.3; Mon, 21 Nov 2016 15:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uzuBTSOBtqbs+fiKGDsLmBkTsYEsmGapVw2MV8bn42s=; b=IJQJSmBnEqpv3wrm1w/CH07jmyBC+qIr5DxksQhn9TmLfgNpEeD+EjjAI3HpDdJok+ jvFMZP3YN1enzOZW/rDMJcFkanDBKUSLh1DUpt87sHehJof/DPgA/7p3L+4OvmN5u3Hr ASMTS48KAl7epTQQTnp6ko/e7k53VAWDBZW9xs8DQcqcYtXGXfnDeksS3lVWzXV8s3sF 2GcmdCsQyW+cySr81byUyyW1Mw43dgUR0b81+lclWrlKljpkW5g3pCX1QjXvmXA215sg IMCj8NezfqH0vHNFXVy33Xl2VFKgnCEo76GFLuqApl1A8wO40a13oQUT30T4XKVdQ08d TlWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uzuBTSOBtqbs+fiKGDsLmBkTsYEsmGapVw2MV8bn42s=; b=LMKQPHNT+eOpWEf7dIzTViFWaWik+x1uMhxwW5A6YeVppHWQKvLgV6b4SX97DOj07y dAfdEJt59AYm+26XDk1+ubTsbvT5Lk7NuRsi2vMGSDgWCzjCtnv8YNPT9g2jAVCC2I0m BUoUl3JlHtEPnPZlgqfd3sfodzl+Zi29Zt4Jti64q6xaSSFPa/aBHfSGUZCOcQzY1Cib OsCvkTSRqMMjhfGQpBGqBTsrZ1I1KgI8hScJ/2Dn48dXSUyUVKEII7ShsrjSErWX24ua jp1NCQTPkwmDjC6xOrD9+b7SrgJB7KTs01keyKai2NOtsjPKTGvNjqlZ3ZDUmiRpWKTy F6sQ== X-Gm-Message-State: AKaTC03u0TIVvcoO6czK0fxFykSFP7rTgwZl3BSigXmN0mSPBkEu4wSty5rY9nWo7bP8Ew== X-Received: by 10.98.67.138 with SMTP id l10mr21949411pfi.101.1479772225275; Mon, 21 Nov 2016 15:50:25 -0800 (PST) Received: from dino-macbook.attlocal.net (adsl-76-254-33-53.dsl.pltn13.sbcglobal.net. [76.254.33.53]) by smtp.gmail.com with ESMTPSA id b64sm39949806pfc.74.2016.11.21.15.50.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2016 15:50:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <5b931a61-0c74-7045-ab1e-f240d762bde3@cs.tcd.ie> Date: Mon, 21 Nov 2016 15:50:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> <5b931a61-0c74-7045-ab1e-f240d762bde3@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, LISP mailing list list , The IESG Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 23:50:28 -0000 Snipping text a bit to make email more readable by third-parties. >>=20 >> It is a canonical form for all new types of addresses or information >> we want to add in the future. >=20 > So maybe I'm being thick but I still don't see how one > reliably orders things when the values are URIs that have > paths with varying case, e.g. URI1=3D"https://example.com/Foo/" > and URI2=3D"https://Example.com:443/foo". Can you explain how one > ensures that all encoders produce the same order for the above > or that it doesn't matter or that one never hits that case with > two URIs being put in order? The ordering is only needed for RLOC addresses. Addresses that are used = for encapsulation. When a distinguished-name is used for an RLOC, it is = ancillary data. I think it is a whole lot simpler then they way you are generally = thinking about it. >>> I don't see the recommendation to not use/send/store this unless >>> needed nor anything other than a generic warning to go read BCP160, >>> which I'm not at all sure is something that would help LISP >>> implementers. Do you really think they'll buy into the geopriv >>> architecture? I don't really. >>>=20 >>> I'd argue that it'd be better to explain the issues here and to >>> recommend to avoid the pitfalls we know exist. >>=20 >> It is here (page 35-36 in -20): >=20 > I don't see that in -21. I see text saying "there might be > some privacy issues... maybe." The discuss point asked that > it state that this information can be privacy sensitive and > hence ought not be sent or stored unless it's needed. I also > don't recall an argument that that kind of text would be wrong. Based on your comment, the details were put in = draft-farinacci-lisp-geo-02. I am not sure we should reference this = draft in the LCAF draft since it is not a working group document. Others = can comment. >>> Are there no LISP use-cases where the Private ETR RLOC Address or=20 >>> RTR RLOC Address could map to a host behind a NAT e.g. in my home? >>=20 >> Yes, kinda. But there is no need for the private-RLOC right now and >> we are working that out in the NAT-traversal individual submission >> draft. >>=20 >>> If there are (and there seem to be many LISP use-cases:-) then=20 >>> maybe this warning is needed. But if not, yes, it'd not be needed.=20= >>> Can you clarify? >>=20 >> We don=E2=80=99t know how ot clarify yet. We can in the future. >=20 > Why can't you fix this now? Why can't you say to not use this > in any cases that might be privacy sensitive and give the example > of exposing information about specific hosts behind a NAT as > an example? The NAT-traversal document says that, = draft-ermagan-lisp-nat-traversal-11. > I don't see why it's better to ignore problems like that, as > we do know that when we ignore such things, they do come back > to bite us in the ass later. We are not ignoring problems at all. We are spec=E2=80=99ing them in = full detail in the use-case documents where there is more supporting = details and context to make these raised issues more understandable. We have this document to defined types that we know we want to use in = the future and have some level of detail on what the content to the = messages should be but don=E2=80=99t have the detailed use-cases for ALL = of them quite yet. In fact, this process has worked very well for us, = because we did predict well and new use-cases have simply said =E2=80=9CUs= e RLE as defined in the LCAF draft=E2=80=9D or =E2=80=9Cuse ELP as = defined in the LCAF draft=E2=80=9D. And there is many use-case drafts = that point to this LCAF draft. >>> LISP-DDT. >>=20 >>> seeing that go by in the discussion of lisp-crypto but I may be >>> forgetting. >>=20 >> So are you good with my response? >=20 > I just had a look back at lisp-crypto and it seems I was remembering > wrong and that doesn't support symmetric keys. Assuming I've not > gotten that wrong again, this one is good:-) lisp-crypto supports symmetric keys. And the reason is because the SAAG = suggested we do so for performance in the data-plane. Remember? ;-) >=20 >>>>> - 4.10.2: The same privacy issues apply here as for 4.3 and >>>>> 4.4, if the MAC address maps to e.g. a portable device carried >>>>> by a person. >>>>=20 >>>> In this case, the MAC address can be a host/person. I put a >>>> refernece to the Security Considersations section that >>>> references RFC6280/BCP160. >>>=20 >>> See above WRT BCP160. I'm really not sure it's a great reference >>> here, in terms of being useful to implementers. >>=20 >> See Security Considerations section. >=20 > I did. That text didn't help. Just referring to BCP160 is > not good enough here IMO, you need some text to call out > the actual issue, which is not called out clearly in that > BCP, which deals with complex location issues in a pretty > complex manner that is not IMO likely to be useful to > LISP implementers. See comment above about draft-farinacci-lisp-geo-02. >>>=20 >>>>> - 4.10.3 and all of section 5: What are these for? I don't see >>>>> the sense in defining these if there is no well defined way to >>>>> use them. Any of these might have undesirable security and/or >>>>> privacy characteristics. >>>>=20 >>>> We have use-cases for them. And they are being documented in >>>> both other working group and individual contributed drafts. >>>=20 >>> Yeah but this seems like throwing the kitchen-sink and all at the >>> mapping system, which seems to me to be a recipe for security and >>> privacy failures. With the level of detail now available, how could >>> we know for sure if I'm right or not? Wouldn't it be better to >>> define these as they are needed and as they are better understood >>> from the security/privacy POV? >>=20 >> They are needed and we are experimenting with them now. We can apply >> updates when we learn more. We still do rough concensus and running >> code. ;-) >=20 > If more than one person writes code then they won't interop > based on this low quality text. Running code does not mean Someone just doesn=E2=80=99t look at this draft and say I want to = implement the RLE LCAF. They say I want to offer = draft-farinacci-lisp-predictive-rlocs or = draft-ietf-lisp-signal-free-multicast in my products, therefore to = support either or both use-cases, I implement the RLE LCAF according to = what those drafts say. It is very specific because I write code for my = own designs (and sometimes it happens backwards to the specs are = detailed and accurate). > it's ok to just sketch out definitions of data structures. > IMO almost all of section 5 would be better deleted from this > until good specification text exists. We have agreement from the working group to go this route. > I don't see a way to resolve this point. If the WG insist on > including types for badly defined structures then I'll just You cannot take read this document in isolation. It is accompanyed with = other drafts (sorry I keep repeating myself). > end up as an abstain on this. Can the chairs or AD confirm > that the WG really have consensus to include all of the > stuff in section 5 at this level of (missing) detail? Yes, we need a mediator if this email doesn=E2=80=99t convince you = Stephen. Thanks, Dino From nobody Tue Nov 22 02:24:26 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4730B129DB0; Tue, 22 Nov 2016 02:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hbP3q-vENpO; Tue, 22 Nov 2016 02:24:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE26129DD7; Tue, 22 Nov 2016 02:20:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71C08BE2F; Tue, 22 Nov 2016 10:20:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urd1WEb33D2s; Tue, 22 Nov 2016 10:20:48 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F92FBE49; Tue, 22 Nov 2016 10:20:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1479810047; bh=oGy58IGPlR836nMWVCyCstAKqsrJG7coBP4n3HBLe78=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=f+BBSKKLtYduOVfLpqwvAOU1UFy5gp2PQ1RAtH4vcDrWgbV9BkriLIqM6yGw0i/rc bWbbdZp/wxWtkiburO2wa9uWM99jNdDtJLs5lLSKAtq60ZpVYQdMazLptPKFj+MU+V 4dpNITiTpGcwwoYXPUN27q5+PmP7bMoKsXjdo/5Q= To: Dino Farinacci References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> <5b931a61-0c74-7045-ab1e-f240d762bde3@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 22 Nov 2016 10:20:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050605090005020707070106" Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, LISP mailing list list , The IESG Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 10:24:18 -0000 This is a cryptographically signed message in MIME format. --------------ms050605090005020707070106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/11/16 23:50, Dino Farinacci wrote: > Snipping text a bit to make email more readable by third-parties. >=20 >>>=20 >>> It is a canonical form for all new types of addresses or >>> information we want to add in the future. >>=20 >> So maybe I'm being thick but I still don't see how one reliably >> orders things when the values are URIs that have paths with varying >> case, e.g. URI1=3D"https://example.com/Foo/" and >> URI2=3D"https://Example.com:443/foo". Can you explain how one ensures >> that all encoders produce the same order for the above or that it >> doesn't matter or that one never hits that case with two URIs being >> put in order? >=20 > The ordering is only needed for RLOC addresses. Addresses that are > used for encapsulation. When a distinguished-name is used for an > RLOC, it is ancillary data. >=20 > I think it is a whole lot simpler then they way you are generally > thinking about it. We're talking past one another. Each time you re-assure me that there's nothing to worry about but don't say how to deal with the case about which I'm asking. Maybe if someone else were to try respond that'd get us out of that loop? :-) >=20 >>>> I don't see the recommendation to not use/send/store this >>>> unless needed nor anything other than a generic warning to go >>>> read BCP160, which I'm not at all sure is something that would >>>> help LISP implementers. Do you really think they'll buy into >>>> the geopriv architecture? I don't really. >>>>=20 >>>> I'd argue that it'd be better to explain the issues here and >>>> to recommend to avoid the pitfalls we know exist. >>>=20 >>> It is here (page 35-36 in -20): >>=20 >> I don't see that in -21. I see text saying "there might be some >> privacy issues... maybe." The discuss point asked that it state >> that this information can be privacy sensitive and hence ought not >> be sent or stored unless it's needed. I also don't recall an >> argument that that kind of text would be wrong. >=20 > Based on your comment, the details were put in > draft-farinacci-lisp-geo-02. I am not sure we should reference this > draft in the LCAF draft since it is not a working group document. > Others can comment. Had you pointed at that draft before? If so, I guess I missed it (and sorry about that). However, BCP160 is *still* not a useful reference there or here, and I was not suggesting referring to that draft (of whose existence I wasn't aware;-). If your argument is that the privacy considerations related to this section of the lcaf draft are dealt with in that lisp-geo draft, then yes I would argue that it needs to be referred to, but I think it'd be better to call out here that location information is privacy sensitive and ought not be used unless it's needed. (And that latter is not stated in the lisp-geo draft.) >=20 >>>> Are there no LISP use-cases where the Private ETR RLOC Address >>>> or RTR RLOC Address could map to a host behind a NAT e.g. in my >>>> home? >>>=20 >>> Yes, kinda. But there is no need for the private-RLOC right now >>> and we are working that out in the NAT-traversal individual >>> submission draft. >>>=20 >>>> If there are (and there seem to be many LISP use-cases:-) then >>>> maybe this warning is needed. But if not, yes, it'd not be >>>> needed. Can you clarify? >>>=20 >>> We don=E2=80=99t know how ot clarify yet. We can in the future. >>=20 >> Why can't you fix this now? Why can't you say to not use this in >> any cases that might be privacy sensitive and give the example of >> exposing information about specific hosts behind a NAT as an >> example? >=20 > The NAT-traversal document says that, > draft-ermagan-lisp-nat-traversal-11. Hmm, another draft of whose existence I wasn't aware. >=20 >> I don't see why it's better to ignore problems like that, as we do >> know that when we ignore such things, they do come back to bite us >> in the ass later. >=20 > We are not ignoring problems at all. We are spec=E2=80=99ing them in fu= ll > detail in the use-case documents where there is more supporting > details and context to make these raised issues more understandable. >=20 > We have this document to defined types that we know we want to use in > the future and have some level of detail on what the content to the > messages should be but don=E2=80=99t have the detailed use-cases for AL= L of > them quite yet. In fact, this process has worked very well for us, > because we did predict well and new use-cases have simply said =E2=80=9C= Use > RLE as defined in the LCAF draft=E2=80=9D or =E2=80=9Cuse ELP as define= d in the LCAF > draft=E2=80=9D. And there is many use-case drafts that point to this LC= AF > draft. I guess I'd argue that that approach has not worked well in terms of covering or even understanding the security and privacy issues that likely arise, if one is to judge from this document and it's references, which is what I'm asked to do. >=20 >>>> LISP-DDT. >>>=20 >>>> seeing that go by in the discussion of lisp-crypto but I may >>>> be forgetting. >>>=20 >>> So are you good with my response? >>=20 >> I just had a look back at lisp-crypto and it seems I was >> remembering wrong and that doesn't support symmetric keys. Assuming >> I've not gotten that wrong again, this one is good:-) >=20 > lisp-crypto supports symmetric keys. And the reason is because the > SAAG suggested we do so for performance in the data-plane. Remember? > ;-) Does it support long-term symmetric keys stored in the format defined here? If so, then more text on that is needed somewhere. If the lcaf format is only for public keys, then it's ok already. >=20 >>=20 >>>>>> - 4.10.2: The same privacy issues apply here as for 4.3 >>>>>> and 4.4, if the MAC address maps to e.g. a portable device >>>>>> carried by a person. >>>>>=20 >>>>> In this case, the MAC address can be a host/person. I put a=20 >>>>> refernece to the Security Considersations section that=20 >>>>> references RFC6280/BCP160. >>>>=20 >>>> See above WRT BCP160. I'm really not sure it's a great >>>> reference here, in terms of being useful to implementers. >>>=20 >>> See Security Considerations section. >>=20 >> I did. That text didn't help. Just referring to BCP160 is not good >> enough here IMO, you need some text to call out the actual issue, >> which is not called out clearly in that BCP, which deals with >> complex location issues in a pretty complex manner that is not IMO >> likely to be useful to LISP implementers. >=20 > See comment above about draft-farinacci-lisp-geo-02. Ditto. Are we talking past one another again? I don't think I've seen any response to the repeated comment that BCP160 is not useful here. >=20 >>>>=20 >>>>>> - 4.10.3 and all of section 5: What are these for? I don't >>>>>> see the sense in defining these if there is no well defined >>>>>> way to use them. Any of these might have undesirable >>>>>> security and/or privacy characteristics. >>>>>=20 >>>>> We have use-cases for them. And they are being documented in=20 >>>>> both other working group and individual contributed drafts. >>>>=20 >>>> Yeah but this seems like throwing the kitchen-sink and all at >>>> the mapping system, which seems to me to be a recipe for >>>> security and privacy failures. With the level of detail now >>>> available, how could we know for sure if I'm right or not? >>>> Wouldn't it be better to define these as they are needed and as >>>> they are better understood from the security/privacy POV? >>>=20 >>> They are needed and we are experimenting with them now. We can >>> apply updates when we learn more. We still do rough concensus and >>> running code. ;-) >>=20 >> If more than one person writes code then they won't interop based >> on this low quality text. Running code does not mean >=20 > Someone just doesn=E2=80=99t look at this draft and say I want to imple= ment > the RLE LCAF. They say I want to offer > draft-farinacci-lisp-predictive-rlocs or > draft-ietf-lisp-signal-free-multicast in my products, therefore to > support either or both use-cases, I implement the RLE LCAF according > to what those drafts say. It is very specific because I write code > for my own designs (and sometimes it happens backwards to the specs > are detailed and accurate). >=20 >> it's ok to just sketch out definitions of data structures. IMO >> almost all of section 5 would be better deleted from this until >> good specification text exists. >=20 > We have agreement from the working group to go this route. >=20 >> I don't see a way to resolve this point. If the WG insist on=20 >> including types for badly defined structures then I'll just >=20 > You cannot take read this document in isolation. It is accompanyed > with other drafts (sorry I keep repeating myself). >=20 >> end up as an abstain on this. Can the chairs or AD confirm that the >> WG really have consensus to include all of the stuff in section 5 >> at this level of (missing) detail? >=20 > Yes, we need a mediator if this email doesn=E2=80=99t convince you Step= hen. We don't need a mediator. If the WG chairs or AD say that the WG want all this text, then I'll move to an abstain once we've sorted the other discuss points. S. >=20 > Thanks, Dino >=20 --------------ms050605090005020707070106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMjIx MDIwNDdaMC8GCSqGSIb3DQEJBDEiBCCI3K67igvh3LmLYeSmzyZwG7IiHw60wBxkFE/9ZBc2 5jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCP/xHRi9psnaJFErhUywEPDVuSp2cDSQmz6DVKj0FZxo1rUSXvlo/9 CtBJIGDctilA6ZGTHRmFNanUJgzNhayHYiNXA/BCBvIgqkj/nqpi1U4b5eNgFVI0/gvqUXq5 nTZamBrLFeAHcWiGUOhzI4c7Sa9OENfLz5GWqbdYlWuA57wm5GUjEQ1OuD51zkJZv40nAbYg Bk4zKlDFN9TrGBSNQamhJkjLdMcKv/OoWOWMvf+BH+T1MpELWzhG7vbm17UEBC1yaDKq6eff zA4XAub2icqqJgFhl8s9PK7qt5hM0lmL45IJbw/Rlw9VX7d1tUnfeFRQAVFfObAWgI8BfUdV AAAAAAAA --------------ms050605090005020707070106-- From nobody Tue Nov 22 10:17:59 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E94B129678; Tue, 22 Nov 2016 10:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhu0cZ8QStXE; Tue, 22 Nov 2016 10:17:55 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B1C129A7A; Tue, 22 Nov 2016 10:17:28 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id p66so2737116pga.2; Tue, 22 Nov 2016 10:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0GbRSgnLrQBwMJjzNTGI5sTC6uD64yZs9Pn9KTaGCUE=; b=fOABaX6iYvGYfwOSd/ik4Nptt2JkYyUlKDGD5GvM/jN9Zl6tVYlACs16tSK0Rcpvjo G5/RNJ6wUA5fTVLQ2eYCNallIOv++1kXPE1RgnZ0gQPw6+44PsORAlLRGwoxhUekklJg FUoKoG28b8caP+TG+uV8k4Gu2gbs2nF3oMUT8omoiqNCr4JxJa3ikNI6KzjFMS2kDW+l sbvZraP7+qyr4MM4RGFG+b7EdaWQ5uSUJgNECk/WACplBYiAgtvdFa4q2ai1rmfSeca0 i6X9x0VVVn1pPvGvGC9BAMvstYk3Hw6QjzKKxv75ME/1wJX81A7gbQnKZrag7pCqVeT0 dCVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0GbRSgnLrQBwMJjzNTGI5sTC6uD64yZs9Pn9KTaGCUE=; b=WNaR0Y11/mN0BGkZJaGAyJd4jnBTkbMbZ4mcg//hNph9aB49resShtEl5pa7R8PWFs mnaxTpvWcwBEWMfTXIl7xroiTrwBvqWyanIS8hEqGKKNQeMeOTBfHjPn68JIBOvoFcGH lxNp1B9mPMLg/k513eFif83w4vnn9EBoftNCukyRoFd6TGGKQ70cHh74MtYw77eJM7Sl dDIqWXJBleHD/rkYRAocPMN8hSQtQ5HZgD07nIFHNwIj3UaDmDPW9FYXKmuzorz4WtjV KQ/x+m5GzypqWb4xUaxyRTYismJ5fG1ugjEvJ0kxMVeK8MHG8eamHWpR94RGzv7PuY4N GE7A== X-Gm-Message-State: AKaTC00RkHcPm9KJ7wsQodmY0Fx9HrCRmG4oYGrExNtPqfF34k8f6JqI5q4aWXQWqnWjEQ== X-Received: by 10.84.216.20 with SMTP id m20mr2209367pli.126.1479838648229; Tue, 22 Nov 2016 10:17:28 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id q12sm46804225pfj.18.2016.11.22.10.17.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 10:17:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: Date: Tue, 22 Nov 2016 10:17:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1515BC7D-0E24-4278-9529-6BE41F7336C1@gmail.com> References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> <5b931a61-0c74-7045-ab1e-f240d762bde3@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, LISP mailing list list , The IESG Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 18:17:57 -0000 > We're talking past one another. Each time you re-assure me > that there's nothing to worry about but don't say how to > deal with the case about which I'm asking. Maybe if someone > else were to try respond that'd get us out of that loop? :-) The chairs are going to respond so we can get out of this loop. > Had you pointed at that draft before? If so, I guess I > missed it (and sorry about that). However, BCP160 is > *still* not a useful reference there or here, and I was > not suggesting referring to that draft (of whose existence > I wasn't aware;-). If your argument is that the privacy > considerations related to this section of the lcaf draft > are dealt with in that lisp-geo draft, then yes I would > argue that it needs to be referred to, but I think it'd > be better to call out here that location information is > privacy sensitive and ought not be used unless it's needed. > (And that latter is not stated in the lisp-geo draft.) I can certainly refer to it as well as the NAT-traversal draft. But want = the chairs to give me their approval. > Does it support long-term symmetric keys stored in the > format defined here? If so, then more text on that is > needed somewhere. If the lcaf format is only for public > keys, then it's ok already. There is no long-term key storage. The format is used only in message = exchange. > We don't need a mediator. If the WG chairs or AD say that the > WG want all this text, then I'll move to an abstain once we've > sorted the other discuss points. Okay, sounds good. Dino From nobody Tue Nov 22 12:37:55 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21A612978B for ; Tue, 22 Nov 2016 12:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xEBZFtVBHjA for ; Tue, 22 Nov 2016 12:37:36 -0800 (PST) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FE2129B6E for ; Tue, 22 Nov 2016 12:37:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 18F2536F385 for ; Tue, 22 Nov 2016 12:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1479847053; bh=ufy95TKYL+d2hUFkPgemYogzjmgrR4HkIAqSGTviOOI=; h=Subject:References:To:From:Date:In-Reply-To:From; b=kqyZc4WWG44wUBpEflbz+UKnnqBee6ugrwbkoeIk2yXbEHfR+eszf2NWCMM8G6mqI O6TmjfMJUyicrzuFnGzSexrrutmfI15AgdVD+lK/BG6XoqKiJLMkVrFyZU4eaMEpHR 2fv8t/DfTv4YYyVHYatufKs7O2TGHwgkJRDB7XNg= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id B65D836046B for ; Tue, 22 Nov 2016 12:37:32 -0800 (PST) References: <147983988739.30322.12665666314505231970.idtracker@ietfa.amsl.com> To: "lisp@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: <147983988739.30322.12665666314505231970.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 22 Nov 2016 15:38:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147983988739.30322.12665666314505231970.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [lisp] Fwd: NomCom 2016-2017: LastCall for Feedback X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 20:37:38 -0000 Please, do give them you rcomments. Yours Joel -------- Forwarded Message -------- Subject: NomCom 2016-2017: LastCall for Feedback Date: Tue, 22 Nov 2016 10:38:07 -0800 From: NomCom Chair 2016 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org Just a reminder that feedback for the current Nominees for IETF and IAB leadership is due by 23:59 UTC on Thursday, November 24, 2016. You can view the list of nominees and enter feedback via the datatracker: https://datatracker.ietf.org/nomcom/2016/feedback/ or you can provide your input by sending email to: nomcom-2016 @ ietf.org You can also send general feedback about Areas, the IESG, The IAB, and the IAOC to the same email address. The NomCom is particularly interested in your feedback on the IAOC and the current nominees given the discussion of IASA 2.0 as outlined in plenary at IETF 97. We would also like to encourage feedback on all of the nominees. Please take a few moments to comment on the full range of nominees in areas where you are active. We have good responses for some but not all of our pool and would appreciate additional input. Lucy Lynch NomCom Chair 2016-2017 llynch @ civil-tongue.net From nobody Thu Nov 24 06:27:27 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C531B1293F2 for ; Thu, 24 Nov 2016 06:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoeTUfhCsjHs for ; Thu, 24 Nov 2016 06:27:21 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E0D129602 for ; Thu, 24 Nov 2016 06:27:20 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t79so63070217wmt.0 for ; Thu, 24 Nov 2016 06:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=HrlvD+HM5ll3PphXLEsqS9nOUXJCN1xfMRM/YqpzYrg=; b=JIRuuIEZpdAhn4KgMkjSiCoCxMsc6tQnKqgZ3eqKQdcZxIAMXfQGrMGS82xxqGSbvw 8wtBNz9K5NtP3kQUYV1oTDeEv2AMmIiPjDj/mEetwSXtzr3XNuwuFNw7dAan2gLBGnyg d1bK+6eyQx6WWWfX2/PBEo6vsVoLuBmx0E4393e9wmdZHaEM7w2IrfpXSUCFBzXUwzej kiVOqjfujsnkEKHeHxUgaZKDYjROY0QJsocBPMpR8R2VMqxvtX7Y/YssqvmvqQgjVBHv ha5G2VZkswSAW2aUNj363aSDuvDoqUFvouF8ngCZXmNMu0A3v4Qk71UkFy87vGWrjDRG GiCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=HrlvD+HM5ll3PphXLEsqS9nOUXJCN1xfMRM/YqpzYrg=; b=PraAVUfSdl15iKdYiBWvZzZI3yonvwpgMVD0Q2GBU3vRICiTuk6uCa2WOuY/JYGDhX jOW3m9fP7KKORGTxKHgGBCpTBRM7aZ/DhsGYlWgzXNTfOMX62xO2RU5bXCdwWI9Qnarp ZFY57auCE6w/b5k44unHHaPjaJfVZfBl53t0wTm/VYRhPRI/NibhS+MutYNocF7YcbdQ Y0GaGY3olbZ2ZZfGImFiRPBMQctvJP9G/Z0bAXz50un3LR/fpn2afbyp80SFSpLa9vmv rEBulWm8UFKigC0hSnzccTztFfgvC9Tlc2TCNqJBx1rI7PgZI9fSR/13xbXdb9QYJGM2 wW4A== X-Gm-Message-State: AKaTC00Me6u8WoLJk+edlFxWobDXgQtY27g+N/EnyB1YDYKAgU+S3RQ+46V3r12ddBB6Sw== X-Received: by 10.28.236.205 with SMTP id h74mr2628689wmi.104.1479997639421; Thu, 24 Nov 2016 06:27:19 -0800 (PST) Received: from ?IPv6:2001:660:330f:38:c153:d010:a655:6a97? ([2001:660:330f:38:c153:d010:a655:6a97]) by smtp.gmail.com with ESMTPSA id ab10sm42028804wjc.45.2016.11.24.06.27.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 06:27:18 -0800 (PST) From: Luigi Iannone Content-Type: multipart/alternative; boundary="Apple-Mail=_0DBD9EE7-4E56-4D44-A4E3-759194093894" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Thu, 24 Nov 2016 15:27:33 +0100 To: LISP mailing list list X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org Subject: [lisp] IETF 97 Minutes X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 14:27:26 -0000 --Apple-Mail=_0DBD9EE7-4E56-4D44-A4E3-759194093894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, minutes of our last meeting are available online at: = https://datatracker.ietf.org/doc/minutes-97-lisp/ = Drop an email if you have any comment or you spot any mistake. Ciao L. --Apple-Mail=_0DBD9EE7-4E56-4D44-A4E3-759194093894 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi All,

minutes of our last meeting are available online at: https://datatracker.ietf.org/doc/minutes-97-lisp/

Drop an email if you have any comment or you spot any mistake.

Ciao

L.

--Apple-Mail=_0DBD9EE7-4E56-4D44-A4E3-759194093894-- From nobody Sun Nov 27 19:09:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255981295A0 for ; Sun, 27 Nov 2016 19:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEQvaDUcXTTo for ; Sun, 27 Nov 2016 19:09:30 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [203.119.102.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A529129597 for ; Sun, 27 Nov 2016 19:09:29 -0800 (PST) Received: from nxmda2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 52a9e021-b517-11e6-b8ce-005056b6ee6f; Mon, 28 Nov 2016 13:04:06 +1000 (AEST) Received: from dhcp148.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Nov 2016 13:03:56 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Mon, 28 Nov 2016 14:04:13 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> References: To: "Zhangxian (Xian)" , X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, lisp@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 03:09:31 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide assistance = to the Routing ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-lisp-type-iana-03.txt=20 Reviewer: Geoff Huston Review Date: 28 November 2016=20 IETF LC End Date: not called=20 Intended Status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors and the IANA. Comments: Draft quality and readability. The third paragraph of the Introduction is unclear. Given that LISP = itself is an experimental specification it is hard to understand the = distinction being made between the "experimentation purposes" and some other undescribed purpose which this reviewer can only conclude is also an experimentation purpose. I suggest re-thinking the intent of this paragraph and expressing it in simpler terms. In section 2, the use of the normative "MUST" seems to be inappropriate, particularly when a non-normative "must" ius used in section 4 in an identical context. Major Issues: It seems anomalous to me that a request to set up an IANA Registry for = an Experimental Protocol (RFC6830 is Experimental) is itself proposed to be = a Standards Track document. Furthermore, the document states that additional values be assigned via = a Standards Action. Again, it appears anomalous to me that a specification of a parameter value of an experimental protocol be described by a Standards Track action. If RFC6830 is revised and is re-published as a Standards Track specification then these points are of course not relevant, but until = such a publication takes place, specifying an IANA parameter registry as a Standards Track action for an experimental protocol seems to me to be anomalous and should not proceed unless the IESG specifically agrees = with this approach. Alternatively RFC5226 could be further revised to=20 explicitly describe the guidelines as they relate to Experimental Specifications (as distinct from experimental allocations within = Standards Track specifications), as this area appears to be unclear from my = reading of RFC5226. However it is not for me to resolve this issue, nor is it up to the = draft authors, or the LISP working group, as far as I can tell. It is up to = the IESG and IANA to clarify this situation and allow IANA to be given clear = directions as to how to maintain parameter registries for experimental = specifications while they remain experiments. From nobody Sun Nov 27 20:02:06 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC4129686; Sun, 27 Nov 2016 20:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN3-YHIUbRnk; Sun, 27 Nov 2016 20:01:59 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B29D129670; Sun, 27 Nov 2016 20:01:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 710041C03B7; Sun, 27 Nov 2016 20:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1480305719; bh=RsU4fcQVp513P6UDnwxc19FSoaV/Jb7qLGXkgAN+TDE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=DsUqEv6Hj0ZcKry0hVozwcfL4z8WMY0mZkGgqSvFW7cFft55SYJ6EMQ400GXdqHxm +tnSwCbxStG61qXksDG9NRhuL9MYTVeObPsLxs5fYX/1wIQeQuQ+fPkDkWDhnKDJ5b E4xU9aIHkGHuRJ9FE11LdqxnSCw//tM/XXrQN0mY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 147E31C0240; Sun, 27 Nov 2016 20:01:58 -0800 (PST) To: Geoff Huston , "Zhangxian (Xian)" , rtg-ads@ietf.org References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> From: "Joel M. Halpern" Message-ID: Date: Sun, 27 Nov 2016 23:01:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: rtg-dir@ietf.org, lisp@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 04:02:01 -0000 You raise an interesting point Geoff. The documents are experimental. As such, it is reasoanble for this document to be experimental, and for it merely to require IETF RFC for assignment, without restricting it to Standards Track RFCs. And while we are in the process of moving the LISP documents to Standards Track, that will take time. However, I would like to be able to have the right status in the documents when we get the upgrade done. We can do a revision of this document as well, but that seems to be creating work. Any suggestions for how to thread this needly? Yours, Joel On 11/27/16 10:04 PM, Geoff Huston wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, > please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-lisp-type-iana-03.txt > Reviewer: Geoff Huston Review > Date: 28 November 2016 > IETF LC End Date: not called > Intended Status: Standards Track > > Summary: > > I have significant concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors and the IANA. > > Comments: > > Draft quality and readability. > > The third paragraph of the Introduction is unclear. Given that LISP itself > is an experimental specification it is hard to understand the distinction > being made between the "experimentation purposes" and some other > undescribed purpose which this reviewer can only conclude is also an > experimentation purpose. I suggest re-thinking the intent of this > paragraph and expressing it in simpler terms. > > In section 2, the use of the normative "MUST" seems to be inappropriate, > particularly when a non-normative "must" ius used in section 4 in an > identical context. > > Major Issues: > > It seems anomalous to me that a request to set up an IANA Registry for an > Experimental Protocol (RFC6830 is Experimental) is itself proposed to be a > Standards Track document. > > Furthermore, the document states that additional values be assigned via a > Standards Action. Again, it appears anomalous to me that a specification > of a parameter value of an experimental protocol be described by a > Standards Track action. > > If RFC6830 is revised and is re-published as a Standards Track > specification then these points are of course not relevant, but until such > a publication takes place, specifying an IANA parameter registry as a > Standards Track action for an experimental protocol seems to me to be > anomalous and should not proceed unless the IESG specifically agrees with > this approach. Alternatively RFC5226 could be further revised to > explicitly describe the guidelines as they relate to Experimental > Specifications (as distinct from experimental allocations within Standards > Track specifications), as this area appears to be unclear from my reading > of RFC5226. > > However it is not for me to resolve this issue, nor is it up to the draft > authors, or the LISP working group, as far as I can tell. It is up to the IESG and > IANA to clarify this situation and allow IANA to be given clear directions > as to how to maintain parameter registries for experimental specifications > while they remain experiments. > > > From nobody Sun Nov 27 20:35:10 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3C91296AE for ; Sun, 27 Nov 2016 20:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PahMfS8zB2GJ for ; Sun, 27 Nov 2016 20:35:06 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C18C1294F7 for ; Sun, 27 Nov 2016 20:35:06 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id fbbece53-b523-11e6-b23e-005056b685e3; Mon, 28 Nov 2016 14:34:43 +1000 (AEST) Received: from dhcp148.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Nov 2016 14:35:01 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: Date: Mon, 28 Nov 2016 15:34:57 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 04:35:09 -0000 I am not fully aware of all the options here, but it strikes me that the = IESG could publish this document as EXPERIMENTAL, consistent with = RFC6830, and in the future whatever mechanism is used to update RFC6830 = to Standards Track, the same document could UPDATE this document and = place it on the standards track by virtue of the Update. There may be other approaches as well, as this is _not_ an area where I = would call myself an =E2=80=9Cexpert=E2=80=9D! regards, Geoff > On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern = wrote: >=20 > You raise an interesting point Geoff. >=20 > The documents are experimental. As such, it is reasoanble for this = document to be experimental, and for it merely to require IETF RFC for = assignment, without restricting it to Standards Track RFCs. >=20 > And while we are in the process of moving the LISP documents to = Standards Track, that will take time. >=20 > However, I would like to be able to have the right status in the = documents when we get the upgrade done. We can do a revision of this = document as well, but that seems to be creating work. >=20 > Any suggestions for how to thread this needly? >=20 > Yours, > Joel >=20 > On 11/27/16 10:04 PM, Geoff Huston wrote: >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. >>=20 >> The Routing Directorate seeks to review all routing or = routing-related >> drafts as they pass through IETF last call and IESG review, and = sometimes >> on special request. The purpose of the review is to provide = assistance to >> the Routing ADs. For more information about the Routing Directorate, >> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it >> would be helpful if you could consider them along with any other IETF = Last >> Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >>=20 >> Document: draft-ietf-lisp-type-iana-03.txt >> Reviewer: Geoff Huston Review >> Date: 28 November 2016 >> IETF LC End Date: not called >> Intended Status: Standards Track >>=20 >> Summary: >>=20 >> I have significant concerns about this document and recommend that = the >> Routing ADs discuss these issues further with the authors and the = IANA. >>=20 >> Comments: >>=20 >> Draft quality and readability. >>=20 >> The third paragraph of the Introduction is unclear. Given that LISP = itself >> is an experimental specification it is hard to understand the = distinction >> being made between the "experimentation purposes" and some other >> undescribed purpose which this reviewer can only conclude is also an >> experimentation purpose. I suggest re-thinking the intent of this >> paragraph and expressing it in simpler terms. >>=20 >> In section 2, the use of the normative "MUST" seems to be = inappropriate, >> particularly when a non-normative "must" ius used in section 4 in an >> identical context. >>=20 >> Major Issues: >>=20 >> It seems anomalous to me that a request to set up an IANA Registry = for an >> Experimental Protocol (RFC6830 is Experimental) is itself proposed to = be a >> Standards Track document. >>=20 >> Furthermore, the document states that additional values be assigned = via a >> Standards Action. Again, it appears anomalous to me that a = specification >> of a parameter value of an experimental protocol be described by a >> Standards Track action. >>=20 >> If RFC6830 is revised and is re-published as a Standards Track >> specification then these points are of course not relevant, but until = such >> a publication takes place, specifying an IANA parameter registry as a >> Standards Track action for an experimental protocol seems to me to be >> anomalous and should not proceed unless the IESG specifically agrees = with >> this approach. Alternatively RFC5226 could be further revised to >> explicitly describe the guidelines as they relate to Experimental >> Specifications (as distinct from experimental allocations within = Standards >> Track specifications), as this area appears to be unclear from my = reading >> of RFC5226. >>=20 >> However it is not for me to resolve this issue, nor is it up to the = draft >> authors, or the LISP working group, as far as I can tell. It is up = to the IESG and >> IANA to clarify this situation and allow IANA to be given clear = directions >> as to how to maintain parameter registries for experimental = specifications >> while they remain experiments. >>=20 >>=20 >>=20 From nobody Sun Nov 27 22:11:07 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E6512944D; Sun, 27 Nov 2016 22:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF4tqQiSdg-Z; Sun, 27 Nov 2016 22:11:01 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D60B128874; Sun, 27 Nov 2016 22:11:01 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 3so12170912pgd.0; Sun, 27 Nov 2016 22:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nROvU2+SgWFVRXCqwu2/hR+JVL5a/AtXnKnK+9W7whQ=; b=vapLZNj5Bnzxtia/P0lZf8WMM/qdeJHnsDh6CwiYzW9jSutfjVGBiacRysXT8cyxGJ vzkhiu+Bh37snNWV4kni8kah64wPsJ850qvxhFcBTtWbY7OkQ/ufEUb394W9Yww9xMuU /6gvhJe4+OsWeBj4RuXR89Z/oPvz/NRO4axN44P0SAAKqiaV+VOJFFBQlChJYcYRj82e eT1MeDfV54J32hi37GoZm+0vgVUZROHIdT0idCWLBZMCcZxszk66TQut0wqA+ziRfCNq xjB9h2VrxTShYDrAMyrpXPRFkiLdhmCZ5CwaVmrUsJM+RzTqfUF0kHjX1GTRHGGCw/FE zLpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nROvU2+SgWFVRXCqwu2/hR+JVL5a/AtXnKnK+9W7whQ=; b=M8l4CrcRbuXo1Y4DdMo8GajAVTkK3F1SMiRKaMo63CZzIiJr2+JchNfhcIKT1VHUBT t2RwE8OdPB0hNRAZZuEIbFpTEl062FtH2NV4W7Me6KIQWmyGCfppcW+e4ZrhqlwQf0Mq lrz6tj+HZRamp1MRMrYDJg7YUFGlRgt+uWu/6DaGx2Egcv/EOmizdtABNfP16LgguBMW tGAHp+rfWQ4JWVUt2FGeDsRyHGlsZ25ekcrMWvHI9koWgKXrlqYRVmduu7EdDLqqNODJ yBbS20/58SYMgvml1+CF/vpzkO0XhAQTpJBS1Z3naPuPdpNxJVGdPIn6y+0wrtVAnDqd UAoA== X-Gm-Message-State: AKaTC02U1+R4kGqEL6MBA7NH13ndUbLFRV7FZAt8IfgTC+fdru+v/dGygEsqvMBeoVM0pg== X-Received: by 10.98.97.7 with SMTP id v7mr19995428pfb.39.1480313460504; Sun, 27 Nov 2016 22:11:00 -0800 (PST) Received: from ?IPv6:2603:3024:151c:55f0:cd67:b6fd:d920:5965? ([2603:3024:151c:55f0:cd67:b6fd:d920:5965]) by smtp.gmail.com with ESMTPSA id v1sm66067892pgv.33.2016.11.27.22.10.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Nov 2016 22:10:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Sun, 27 Nov 2016 22:10:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> To: Geoff Huston Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 06:11:03 -0000 I think this is a good and expedient suggestion.=20 Dino > On Nov 27, 2016, at 8:34 PM, Geoff Huston wrote: >=20 > I am not fully aware of all the options here, but it strikes me that the I= ESG could publish this document as EXPERIMENTAL, consistent with RFC6830, an= d in the future whatever mechanism is used to update RFC6830 to Standards Tr= ack, the same document could UPDATE this document and place it on the standa= rds track by virtue of the Update. >=20 > There may be other approaches as well, as this is _not_ an area where I wo= uld call myself an =E2=80=9Cexpert=E2=80=9D! >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern wrote:= >>=20 >> You raise an interesting point Geoff. >>=20 >> The documents are experimental. As such, it is reasoanble for this docum= ent to be experimental, and for it merely to require IETF RFC for assignment= , without restricting it to Standards Track RFCs. >>=20 >> And while we are in the process of moving the LISP documents to Standards= Track, that will take time. >>=20 >> However, I would like to be able to have the right status in the document= s when we get the upgrade done. We can do a revision of this document as we= ll, but that seems to be creating work. >>=20 >> Any suggestions for how to thread this needly? >>=20 >> Yours, >> Joel >>=20 >>> On 11/27/16 10:04 PM, Geoff Huston wrote: >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this draft.= >>>=20 >>> The Routing Directorate seeks to review all routing or routing-related >>> drafts as they pass through IETF last call and IESG review, and sometime= s >>> on special request. The purpose of the review is to provide assistance t= o >>> the Routing ADs. For more information about the Routing Directorate, >>> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir= >>>=20 >>> Although these comments are primarily for the use of the Routing ADs, it= >>> would be helpful if you could consider them along with any other IETF La= st >>> Call comments that you receive, and strive to resolve them through >>> discussion or by updating the draft. >>>=20 >>> Document: draft-ietf-lisp-type-iana-03.txt >>> Reviewer: Geoff Huston Review >>> Date: 28 November 2016 >>> IETF LC End Date: not called >>> Intended Status: Standards Track >>>=20 >>> Summary: >>>=20 >>> I have significant concerns about this document and recommend that the >>> Routing ADs discuss these issues further with the authors and the IANA. >>>=20 >>> Comments: >>>=20 >>> Draft quality and readability. >>>=20 >>> The third paragraph of the Introduction is unclear. Given that LISP itse= lf >>> is an experimental specification it is hard to understand the distinctio= n >>> being made between the "experimentation purposes" and some other >>> undescribed purpose which this reviewer can only conclude is also an >>> experimentation purpose. I suggest re-thinking the intent of this >>> paragraph and expressing it in simpler terms. >>>=20 >>> In section 2, the use of the normative "MUST" seems to be inappropriate,= >>> particularly when a non-normative "must" ius used in section 4 in an >>> identical context. >>>=20 >>> Major Issues: >>>=20 >>> It seems anomalous to me that a request to set up an IANA Registry for a= n >>> Experimental Protocol (RFC6830 is Experimental) is itself proposed to be= a >>> Standards Track document. >>>=20 >>> Furthermore, the document states that additional values be assigned via a= >>> Standards Action. Again, it appears anomalous to me that a specification= >>> of a parameter value of an experimental protocol be described by a >>> Standards Track action. >>>=20 >>> If RFC6830 is revised and is re-published as a Standards Track >>> specification then these points are of course not relevant, but until su= ch >>> a publication takes place, specifying an IANA parameter registry as a >>> Standards Track action for an experimental protocol seems to me to be >>> anomalous and should not proceed unless the IESG specifically agrees wit= h >>> this approach. Alternatively RFC5226 could be further revised to >>> explicitly describe the guidelines as they relate to Experimental >>> Specifications (as distinct from experimental allocations within Standar= ds >>> Track specifications), as this area appears to be unclear from my readin= g >>> of RFC5226. >>>=20 >>> However it is not for me to resolve this issue, nor is it up to the draf= t >>> authors, or the LISP working group, as far as I can tell. It is up to t= he IESG and >>> IANA to clarify this situation and allow IANA to be given clear directio= ns >>> as to how to maintain parameter registries for experimental specificatio= ns >>> while they remain experiments. >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 01:13:04 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A0F1296DF for ; Mon, 28 Nov 2016 01:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52lfHFWss_va for ; Mon, 28 Nov 2016 01:12:59 -0800 (PST) Received: from mail-wj0-x243.google.com (mail-wj0-x243.google.com [IPv6:2a00:1450:400c:c01::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9AA1296DE for ; Mon, 28 Nov 2016 01:12:57 -0800 (PST) Received: by mail-wj0-x243.google.com with SMTP id xy5so13168668wjc.1 for ; Mon, 28 Nov 2016 01:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IexylFLX9eGuCG/tfR8OhaWpArGlaNdoYLT56G765fU=; b=rfhztQkgoxXkYHYLWiWmzJHznJhOGP3gwZdOHUDMeGtr4ZBCGUhRSmmi5N60nn5yCK 9bKVBQ/j/jbsT444+8DGv/lXNb5eRWuQFyZ0bMSHpqmaP0CLbTjdCDx1zYwBPkhl5tJ2 EEukmxWn/YlMYpK021W4faLY/FoT8uNomqvTMstuFUQFnp2jGX1V6A+l6veqVGL1M0BN hK578UskBK+h/Lt+PrZz37327Wy8jyaPO5daltdHMr+oFdFjuZva6cr6o1VVi4Zir/fG UK2C7guomuckwwp5zVyRcm0tGYWnYgVk5GhLWJRI1T84qqJC7iJOl5hva8V2nHc+dW5f xNWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IexylFLX9eGuCG/tfR8OhaWpArGlaNdoYLT56G765fU=; b=k5l5dMNff3xXl1KYRZLv/jhUm4B5Oj+cb41NdwQO6tx3kwtuVd52L8oiiMCKc0T2Av 5b6SeMfutxOFOd48hfThW8JVXXCN5vU90k/TlOGov1kLaKYi+fZJiUeI2dlu1A1c8vG2 xR/TihJLgJq7lu6OZ6JbYbmOWQjOJVdqmmUt1PhnrDS8d0jTdwKfiPED7Kcl1yMp9XaP K34d9K8Z/wqY07Q90agCfFQC/S2MnuuFyV9Wrxk6JnBaMP7DpKrHNuPCYf+f4eiduuli 1mIaVGMGTB5jiOA0RVP+tJfDCsmP2VVljby8RGZYPbBvTbvHHpriExDi/+Ugp+tORmnG OH0g== X-Gm-Message-State: AKaTC02Ajim9z2/zJGiYxoZwN8ov5oVvRTh864sw8GICib/OAUCdcAgX1JxdsxvW4D2rfA== X-Received: by 10.194.60.195 with SMTP id j3mr18540833wjr.149.1480324375522; Mon, 28 Nov 2016 01:12:55 -0800 (PST) Received: from ?IPv6:2a01:e35:1381:3430:502b:7c76:76a7:6c22? ([2a01:e35:1381:3430:502b:7c76:76a7:6c22]) by smtp.gmail.com with ESMTPSA id ef10sm41845718wjd.22.2016.11.28.01.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 01:12:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Luigi Iannone In-Reply-To: Date: Mon, 28 Nov 2016 10:12:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 09:13:01 -0000 Hi Geoff, > On 28 Nov 2016, at 05:34, Geoff Huston wrote: >=20 > I am not fully aware of all the options here, but it strikes me that = the IESG could publish this document as EXPERIMENTAL, consistent with = RFC6830, and in the future whatever mechanism is used to update RFC6830 = to Standards Track, the same document could UPDATE this document and = place it on the standards track by virtue of the Update. Just for clarity. You suggest We publish this document as experimental now. Then we merge the standard = track update in the same document that updates 6830 as standard track. Am I right? An alternative option (with less work to do) is to keep this document = on hold until there will be the standard track update of 6830. At that point, there will not be any issue in publishing the document as = well as standard track. In this way we do not need to work on merging the document with the 6830 = update and we still solve the issue you raised. Any thought ? ciao L. =20 >=20 > There may be other approaches as well, as this is _not_ an area where = I would call myself an =E2=80=9Cexpert=E2=80=9D! >=20 > regards, >=20 > Geoff >=20 >=20 >=20 >> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern = wrote: >>=20 >> You raise an interesting point Geoff. >>=20 >> The documents are experimental. As such, it is reasoanble for this = document to be experimental, and for it merely to require IETF RFC for = assignment, without restricting it to Standards Track RFCs. >>=20 >> And while we are in the process of moving the LISP documents to = Standards Track, that will take time. >>=20 >> However, I would like to be able to have the right status in the = documents when we get the upgrade done. We can do a revision of this = document as well, but that seems to be creating work. >>=20 >> Any suggestions for how to thread this needly? >>=20 >> Yours, >> Joel >>=20 >> On 11/27/16 10:04 PM, Geoff Huston wrote: >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this = draft. >>>=20 >>> The Routing Directorate seeks to review all routing or = routing-related >>> drafts as they pass through IETF last call and IESG review, and = sometimes >>> on special request. The purpose of the review is to provide = assistance to >>> the Routing ADs. For more information about the Routing Directorate, >>> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgD= ir >>>=20 >>> Although these comments are primarily for the use of the Routing = ADs, it >>> would be helpful if you could consider them along with any other = IETF Last >>> Call comments that you receive, and strive to resolve them through >>> discussion or by updating the draft. >>>=20 >>> Document: draft-ietf-lisp-type-iana-03.txt >>> Reviewer: Geoff Huston Review >>> Date: 28 November 2016 >>> IETF LC End Date: not called >>> Intended Status: Standards Track >>>=20 >>> Summary: >>>=20 >>> I have significant concerns about this document and recommend that = the >>> Routing ADs discuss these issues further with the authors and the = IANA. >>>=20 >>> Comments: >>>=20 >>> Draft quality and readability. >>>=20 >>> The third paragraph of the Introduction is unclear. Given that LISP = itself >>> is an experimental specification it is hard to understand the = distinction >>> being made between the "experimentation purposes" and some other >>> undescribed purpose which this reviewer can only conclude is also an >>> experimentation purpose. I suggest re-thinking the intent of this >>> paragraph and expressing it in simpler terms. >>>=20 >>> In section 2, the use of the normative "MUST" seems to be = inappropriate, >>> particularly when a non-normative "must" ius used in section 4 in an >>> identical context. >>>=20 >>> Major Issues: >>>=20 >>> It seems anomalous to me that a request to set up an IANA Registry = for an >>> Experimental Protocol (RFC6830 is Experimental) is itself proposed = to be a >>> Standards Track document. >>>=20 >>> Furthermore, the document states that additional values be assigned = via a >>> Standards Action. Again, it appears anomalous to me that a = specification >>> of a parameter value of an experimental protocol be described by a >>> Standards Track action. >>>=20 >>> If RFC6830 is revised and is re-published as a Standards Track >>> specification then these points are of course not relevant, but = until such >>> a publication takes place, specifying an IANA parameter registry as = a >>> Standards Track action for an experimental protocol seems to me to = be >>> anomalous and should not proceed unless the IESG specifically agrees = with >>> this approach. Alternatively RFC5226 could be further revised to >>> explicitly describe the guidelines as they relate to Experimental >>> Specifications (as distinct from experimental allocations within = Standards >>> Track specifications), as this area appears to be unclear from my = reading >>> of RFC5226. >>>=20 >>> However it is not for me to resolve this issue, nor is it up to the = draft >>> authors, or the LISP working group, as far as I can tell. It is up = to the IESG and >>> IANA to clarify this situation and allow IANA to be given clear = directions >>> as to how to maintain parameter registries for experimental = specifications >>> while they remain experiments. >>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 02:01:40 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB45129A62 for ; Mon, 28 Nov 2016 02:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvDEtobH-o1X for ; Mon, 28 Nov 2016 02:01:38 -0800 (PST) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140A712998F for ; Mon, 28 Nov 2016 01:58:25 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon) with ESMTPS id 269d3f95-b551-11e6-b23e-005056b685e3; Mon, 28 Nov 2016 19:58:03 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Nov 2016 19:58:20 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> Date: Mon, 28 Nov 2016 20:58:15 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> To: Luigi Iannone X-Mailer: Apple Mail (2.3251) Archived-At: Cc: rtg-dir@ietf.org, "Zhangxian \(Xian\)" , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 10:01:40 -0000 Hi Luigi, If you think that it would be useful to open up an IANA registry now, = then I would not wait i.e. I=E2=80=99d publish the document as = EXPERIMENTAL and update it into the standards track when you update = RFC6830. On the other hand, if the IANA registry is not needed at once then it = could all wait.=20 Personally, I find deferral options difficult to remember and pick up = the threads - so I normally do things on the day and then adjust as = required down the track - but that's more about my preferred way to = work! kind regards, Geoff > On 28 Nov. 2016, at 8:12 pm, Luigi Iannone wrote: >=20 > Hi Geoff, >> On 28 Nov 2016, at 05:34, Geoff Huston wrote: >>=20 >> I am not fully aware of all the options here, but it strikes me that = the IESG could publish this document as EXPERIMENTAL, consistent with = RFC6830, and in the future whatever mechanism is used to update RFC6830 = to Standards Track, the same document could UPDATE this document and = place it on the standards track by virtue of the Update. >=20 > Just for clarity. >=20 > You suggest >=20 > We publish this document as experimental now. Then we merge the = standard track update in the same document that updates 6830 as standard = track. >=20 > Am I right? >=20 > An alternative option (with less work to do) is to keep this = document on hold until there will be the standard track update of 6830. > At that point, there will not be any issue in publishing the document = as well as standard track. >=20 > In this way we do not need to work on merging the document with the = 6830 update and we still solve the issue you raised. >=20 > Any thought ? >=20 > ciao >=20 > L. >=20 >=20 >=20 >>=20 >> There may be other approaches as well, as this is _not_ an area where = I would call myself an =E2=80=9Cexpert=E2=80=9D! >>=20 >> regards, >>=20 >> Geoff >>=20 >>=20 >>=20 >>> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern = wrote: >>>=20 >>> You raise an interesting point Geoff. >>>=20 >>> The documents are experimental. As such, it is reasoanble for this = document to be experimental, and for it merely to require IETF RFC for = assignment, without restricting it to Standards Track RFCs. >>>=20 >>> And while we are in the process of moving the LISP documents to = Standards Track, that will take time. >>>=20 >>> However, I would like to be able to have the right status in the = documents when we get the upgrade done. We can do a revision of this = document as well, but that seems to be creating work. >>>=20 >>> Any suggestions for how to thread this needly? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 11/27/16 10:04 PM, Geoff Huston wrote: >>>> Hello, >>>>=20 >>>> I have been selected as the Routing Directorate reviewer for this = draft. >>>>=20 >>>> The Routing Directorate seeks to review all routing or = routing-related >>>> drafts as they pass through IETF last call and IESG review, and = sometimes >>>> on special request. The purpose of the review is to provide = assistance to >>>> the Routing ADs. For more information about the Routing = Directorate, >>>> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg= Dir >>>>=20 >>>> Although these comments are primarily for the use of the Routing = ADs, it >>>> would be helpful if you could consider them along with any other = IETF Last >>>> Call comments that you receive, and strive to resolve them through >>>> discussion or by updating the draft. >>>>=20 >>>> Document: draft-ietf-lisp-type-iana-03.txt >>>> Reviewer: Geoff Huston Review >>>> Date: 28 November 2016 >>>> IETF LC End Date: not called >>>> Intended Status: Standards Track >>>>=20 >>>> Summary: >>>>=20 >>>> I have significant concerns about this document and recommend that = the >>>> Routing ADs discuss these issues further with the authors and the = IANA. >>>>=20 >>>> Comments: >>>>=20 >>>> Draft quality and readability. >>>>=20 >>>> The third paragraph of the Introduction is unclear. Given that LISP = itself >>>> is an experimental specification it is hard to understand the = distinction >>>> being made between the "experimentation purposes" and some other >>>> undescribed purpose which this reviewer can only conclude is also = an >>>> experimentation purpose. I suggest re-thinking the intent of this >>>> paragraph and expressing it in simpler terms. >>>>=20 >>>> In section 2, the use of the normative "MUST" seems to be = inappropriate, >>>> particularly when a non-normative "must" ius used in section 4 in = an >>>> identical context. >>>>=20 >>>> Major Issues: >>>>=20 >>>> It seems anomalous to me that a request to set up an IANA Registry = for an >>>> Experimental Protocol (RFC6830 is Experimental) is itself proposed = to be a >>>> Standards Track document. >>>>=20 >>>> Furthermore, the document states that additional values be assigned = via a >>>> Standards Action. Again, it appears anomalous to me that a = specification >>>> of a parameter value of an experimental protocol be described by a >>>> Standards Track action. >>>>=20 >>>> If RFC6830 is revised and is re-published as a Standards Track >>>> specification then these points are of course not relevant, but = until such >>>> a publication takes place, specifying an IANA parameter registry as = a >>>> Standards Track action for an experimental protocol seems to me to = be >>>> anomalous and should not proceed unless the IESG specifically = agrees with >>>> this approach. Alternatively RFC5226 could be further revised to >>>> explicitly describe the guidelines as they relate to Experimental >>>> Specifications (as distinct from experimental allocations within = Standards >>>> Track specifications), as this area appears to be unclear from my = reading >>>> of RFC5226. >>>>=20 >>>> However it is not for me to resolve this issue, nor is it up to the = draft >>>> authors, or the LISP working group, as far as I can tell. It is up = to the IESG and >>>> IANA to clarify this situation and allow IANA to be given clear = directions >>>> as to how to maintain parameter registries for experimental = specifications >>>> while they remain experiments. >>>>=20 >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 From nobody Mon Nov 28 05:14:58 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24EB129F21; Mon, 28 Nov 2016 05:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFSLI5o6lg-0; Mon, 28 Nov 2016 05:14:48 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF14129F1B; Mon, 28 Nov 2016 05:14:48 -0800 (PST) Received: from [206.123.31.198] (h198.viagenie.ca [206.123.31.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6DE244757B; Mon, 28 Nov 2016 08:14:47 -0500 (EST) From: "Marc Blanchet" To: "Geoff Huston" Date: Mon, 28 Nov 2016 08:14:48 -0500 Message-ID: <291FCB7C-AC8A-40C4-8602-3731CB02751A@viagenie.ca> In-Reply-To: References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <94229B70-47C3-4FB5-8906-9CD4CC672D10@gigix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5307) Archived-At: Cc: rtg-dir@ietf.org, Zhangxian , lisp@ietf.org, rtg-ads@ietf.org, "jonathan.hardwick@metaswitch.com" , draft-ietf-lisp-type-iana.all@ietf.org, Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:14:54 -0000 On 28 Nov 2016, at 4:58, Geoff Huston wrote: > Hi Luigi, > > If you think that it would be useful to open up an IANA registry now, > then I would not wait i.e. I’d publish the document as EXPERIMENTAL > and update it into the standards track when you update RFC6830. FYI, dtnrg had his specs as experimental. After some good experimentation with wg managed registries, we end up creating an RFC to register all the parameters. That RFC (6255) was Informational. Marc. > > On the other hand, if the IANA registry is not needed at once then it > could all wait. > > Personally, I find deferral options difficult to remember and pick up > the threads - so I normally do things on the day and then adjust as > required down the track - but that's more about my preferred way to > work! > > kind regards, > > Geoff > > > > >> On 28 Nov. 2016, at 8:12 pm, Luigi Iannone wrote: >> >> Hi Geoff, >>> On 28 Nov 2016, at 05:34, Geoff Huston wrote: >>> >>> I am not fully aware of all the options here, but it strikes me that >>> the IESG could publish this document as EXPERIMENTAL, consistent >>> with RFC6830, and in the future whatever mechanism is used to update >>> RFC6830 to Standards Track, the same document could UPDATE this >>> document and place it on the standards track by virtue of the >>> Update. >> >> Just for clarity. >> >> You suggest >> >> We publish this document as experimental now. Then we merge the >> standard track update in the same document that updates 6830 as >> standard track. >> >> Am I right? >> >> An alternative option (with less work to do) is to keep this >> document on hold until there will be the standard track update of >> 6830. >> At that point, there will not be any issue in publishing the document >> as well as standard track. >> >> In this way we do not need to work on merging the document with the >> 6830 update and we still solve the issue you raised. >> >> Any thought ? >> >> ciao >> >> L. >> >> >> >>> >>> There may be other approaches as well, as this is _not_ an area >>> where I would call myself an “expert”! >>> >>> regards, >>> >>> Geoff >>> >>> >>> >>>> On 28 Nov. 2016, at 3:01 pm, Joel M. Halpern >>>> wrote: >>>> >>>> You raise an interesting point Geoff. >>>> >>>> The documents are experimental. As such, it is reasoanble for this >>>> document to be experimental, and for it merely to require IETF RFC >>>> for assignment, without restricting it to Standards Track RFCs. >>>> >>>> And while we are in the process of moving the LISP documents to >>>> Standards Track, that will take time. >>>> >>>> However, I would like to be able to have the right status in the >>>> documents when we get the upgrade done. We can do a revision of >>>> this document as well, but that seems to be creating work. >>>> >>>> Any suggestions for how to thread this needly? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/27/16 10:04 PM, Geoff Huston wrote: >>>>> Hello, >>>>> >>>>> I have been selected as the Routing Directorate reviewer for this >>>>> draft. >>>>> >>>>> The Routing Directorate seeks to review all routing or >>>>> routing-related >>>>> drafts as they pass through IETF last call and IESG review, and >>>>> sometimes >>>>> on special request. The purpose of the review is to provide >>>>> assistance to >>>>> the Routing ADs. For more information about the Routing >>>>> Directorate, >>>>> please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>>> >>>>> Although these comments are primarily for the use of the Routing >>>>> ADs, it >>>>> would be helpful if you could consider them along with any other >>>>> IETF Last >>>>> Call comments that you receive, and strive to resolve them through >>>>> discussion or by updating the draft. >>>>> >>>>> Document: draft-ietf-lisp-type-iana-03.txt >>>>> Reviewer: Geoff Huston Review >>>>> Date: 28 November 2016 >>>>> IETF LC End Date: not called >>>>> Intended Status: Standards Track >>>>> >>>>> Summary: >>>>> >>>>> I have significant concerns about this document and recommend that >>>>> the >>>>> Routing ADs discuss these issues further with the authors and the >>>>> IANA. >>>>> >>>>> Comments: >>>>> >>>>> Draft quality and readability. >>>>> >>>>> The third paragraph of the Introduction is unclear. Given that >>>>> LISP itself >>>>> is an experimental specification it is hard to understand the >>>>> distinction >>>>> being made between the "experimentation purposes" and some other >>>>> undescribed purpose which this reviewer can only conclude is also >>>>> an >>>>> experimentation purpose. I suggest re-thinking the intent of this >>>>> paragraph and expressing it in simpler terms. >>>>> >>>>> In section 2, the use of the normative "MUST" seems to be >>>>> inappropriate, >>>>> particularly when a non-normative "must" ius used in section 4 in >>>>> an >>>>> identical context. >>>>> >>>>> Major Issues: >>>>> >>>>> It seems anomalous to me that a request to set up an IANA Registry >>>>> for an >>>>> Experimental Protocol (RFC6830 is Experimental) is itself proposed >>>>> to be a >>>>> Standards Track document. >>>>> >>>>> Furthermore, the document states that additional values be >>>>> assigned via a >>>>> Standards Action. Again, it appears anomalous to me that a >>>>> specification >>>>> of a parameter value of an experimental protocol be described by a >>>>> Standards Track action. >>>>> >>>>> If RFC6830 is revised and is re-published as a Standards Track >>>>> specification then these points are of course not relevant, but >>>>> until such >>>>> a publication takes place, specifying an IANA parameter registry >>>>> as a >>>>> Standards Track action for an experimental protocol seems to me to >>>>> be >>>>> anomalous and should not proceed unless the IESG specifically >>>>> agrees with >>>>> this approach. Alternatively RFC5226 could be further revised to >>>>> explicitly describe the guidelines as they relate to Experimental >>>>> Specifications (as distinct from experimental allocations within >>>>> Standards >>>>> Track specifications), as this area appears to be unclear from my >>>>> reading >>>>> of RFC5226. >>>>> >>>>> However it is not for me to resolve this issue, nor is it up to >>>>> the draft >>>>> authors, or the LISP working group, as far as I can tell. It is >>>>> up to the IESG and >>>>> IANA to clarify this situation and allow IANA to be given clear >>>>> directions >>>>> as to how to maintain parameter registries for experimental >>>>> specifications >>>>> while they remain experiments. >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 05:47:53 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC15A129417; Mon, 28 Nov 2016 05:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC4P7ebjtHhB; Mon, 28 Nov 2016 05:47:50 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AE012952F; Mon, 28 Nov 2016 05:43:32 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 47EF0602E2; Mon, 28 Nov 2016 14:43:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 1EA90C009B; Mon, 28 Nov 2016 14:43:30 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 14:43:29 +0100 From: To: Geoff Huston , "Zhangxian (Xian)" , "rtg-ads@ietf.org" Thread-Topic: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSSTZkTJXs+jI90y9VfbdmaPmWaDuYMHA Date: Mon, 28 Nov 2016 13:43:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> In-Reply-To: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "jonathan.hardwick@metaswitch.com" , "rtg-dir@ietf.org" , "draft-ietf-lisp-type-iana.all@ietf.org" , "lisp@ietf.org" , Jon Hudson Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:47:52 -0000 SGkgR29lZmYsIA0KDQpJIGhhdmUgb25lIGNvbW1lbnQgYWJvdXQgdGhpcyBwYXJ0IG9mIHlvdXIg cmV2aWV3OiANCg0KPiBJdCBzZWVtcyBhbm9tYWxvdXMgdG8gbWUgdGhhdCBhIHJlcXVlc3QgdG8g c2V0IHVwIGFuIElBTkEgUmVnaXN0cnkgZm9yIGFuDQo+IEV4cGVyaW1lbnRhbCBQcm90b2NvbCAo UkZDNjgzMCBpcyBFeHBlcmltZW50YWwpIGlzIGl0c2VsZiBwcm9wb3NlZCB0byBiZSBhDQo+IFN0 YW5kYXJkcyBUcmFjayBkb2N1bWVudC4NCg0KRldJVywgSSdtIGF3YXJlIG9mIGFuIElBTkEgcmVn aXN0cnkgZm9yIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCB0aGF0IHlvdSBjYW4gY2hlY2sgaGVy ZTogDQpodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1wYXJhbWV0ZXJzL3RjcC1w YXJhbWV0ZXJzLnhodG1sI21wdGNwLW9wdGlvbi1zdWJ0eXBlcyANCg0KQ2hlZXJzLA0KTWVkDQoN Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGxpc3AgW21haWx0bzpsaXNw LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgR2VvZmYgSHVzdG9uDQo+IEVudm95w6nC oDogbHVuZGkgMjggbm92ZW1icmUgMjAxNiAwNDowNA0KPiDDgMKgOiBaaGFuZ3hpYW4gKFhpYW4p OyBydGctYWRzQGlldGYub3JnDQo+IENjwqA6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGxpc3BAaWV0Zi5v cmc7IGpvbmF0aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tOw0KPiBkcmFmdC1pZXRmLWxpc3At dHlwZS1pYW5hLmFsbEBpZXRmLm9yZzsgSm9uIEh1ZHNvbg0KPiBPYmpldMKgOiBbbGlzcF0gUnRn RGlyIHJldmlldzogZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gDQo+IEhlbGxv LA0KPiANCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQo+IA0KPiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBz ZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+IGRyYWZ0cyBh cyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBz b21ldGltZXMNCj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3 IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0bw0KPiB0aGUgUm91dGluZyBBRHMuIEZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLA0KPiBwbGVhc2Ugc2Vl IOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIN Cj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBj b25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBDYWxsIGNvbW1l bnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gN Cj4gZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDog ZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gUmV2aWV3ZXI6IEdlb2ZmIEh1c3Rv biBSZXZpZXcNCj4gRGF0ZTogMjggTm92ZW1iZXIgMjAxNg0KPiBJRVRGIExDIEVuZCBEYXRlOiBu b3QgY2FsbGVkDQo+IEludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrDQo+IA0KPiBTdW1t YXJ5Og0KPiANCj4gSSBoYXZlIHNpZ25pZmljYW50IGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1l bnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZQ0KPiBSb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlz c3VlcyBmdXJ0aGVyIHdpdGggdGhlIGF1dGhvcnMgYW5kIHRoZSBJQU5BLg0KPiANCj4gQ29tbWVu dHM6DQo+IA0KPiBEcmFmdCBxdWFsaXR5IGFuZCByZWFkYWJpbGl0eS4NCj4gDQo+IFRoZSB0aGly ZCBwYXJhZ3JhcGggb2YgdGhlIEludHJvZHVjdGlvbiBpcyB1bmNsZWFyLiBHaXZlbiB0aGF0IExJ U1AgaXRzZWxmDQo+IGlzIGFuIGV4cGVyaW1lbnRhbCBzcGVjaWZpY2F0aW9uIGl0IGlzIGhhcmQg dG8gdW5kZXJzdGFuZCB0aGUgZGlzdGluY3Rpb24NCj4gYmVpbmcgbWFkZSBiZXR3ZWVuIHRoZSAi ZXhwZXJpbWVudGF0aW9uIHB1cnBvc2VzIiBhbmQgc29tZSBvdGhlcg0KPiB1bmRlc2NyaWJlZCBw dXJwb3NlIHdoaWNoIHRoaXMgcmV2aWV3ZXIgY2FuIG9ubHkgY29uY2x1ZGUgaXMgYWxzbyBhbg0K PiBleHBlcmltZW50YXRpb24gcHVycG9zZS4gSSBzdWdnZXN0IHJlLXRoaW5raW5nIHRoZSBpbnRl bnQgb2YgdGhpcw0KPiBwYXJhZ3JhcGggYW5kIGV4cHJlc3NpbmcgaXQgaW4gc2ltcGxlciB0ZXJt cy4NCj4gDQo+IEluIHNlY3Rpb24gMiwgdGhlIHVzZSBvZiB0aGUgbm9ybWF0aXZlICJNVVNUIiBz ZWVtcyB0byBiZSBpbmFwcHJvcHJpYXRlLA0KPiBwYXJ0aWN1bGFybHkgd2hlbiBhIG5vbi1ub3Jt YXRpdmUgIm11c3QiIGl1cyB1c2VkIGluIHNlY3Rpb24gNCBpbiBhbg0KPiBpZGVudGljYWwgY29u dGV4dC4NCj4gDQo+IE1ham9yIElzc3VlczoNCj4gDQo+IEl0IHNlZW1zIGFub21hbG91cyB0byBt ZSB0aGF0IGEgcmVxdWVzdCB0byBzZXQgdXAgYW4gSUFOQSBSZWdpc3RyeSBmb3IgYW4NCj4gRXhw ZXJpbWVudGFsIFByb3RvY29sIChSRkM2ODMwIGlzIEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHBy b3Bvc2VkIHRvIGJlIGENCj4gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50Lg0KPiANCj4gRnVydGhl cm1vcmUsIHRoZSBkb2N1bWVudCBzdGF0ZXMgdGhhdCBhZGRpdGlvbmFsIHZhbHVlcyBiZSBhc3Np Z25lZCB2aWEgYQ0KPiBTdGFuZGFyZHMgQWN0aW9uLiBBZ2FpbiwgaXQgYXBwZWFycyBhbm9tYWxv dXMgdG8gbWUgdGhhdCBhIHNwZWNpZmljYXRpb24NCj4gb2YgYSBwYXJhbWV0ZXIgdmFsdWUgb2Yg YW4gZXhwZXJpbWVudGFsIHByb3RvY29sIGJlIGRlc2NyaWJlZCBieSBhDQo+IFN0YW5kYXJkcyBU cmFjayBhY3Rpb24uDQo+IA0KPiBJZiBSRkM2ODMwIGlzIHJldmlzZWQgYW5kIGlzIHJlLXB1Ymxp c2hlZCBhcyBhIFN0YW5kYXJkcyBUcmFjaw0KPiBzcGVjaWZpY2F0aW9uIHRoZW4gdGhlc2UgcG9p bnRzIGFyZSBvZiBjb3Vyc2Ugbm90IHJlbGV2YW50LCBidXQgdW50aWwgc3VjaA0KPiBhIHB1Ymxp Y2F0aW9uIHRha2VzIHBsYWNlLCBzcGVjaWZ5aW5nIGFuIElBTkEgcGFyYW1ldGVyIHJlZ2lzdHJ5 IGFzIGENCj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhwZXJpbWVudGFsIHByb3Rv Y29sIHNlZW1zIHRvIG1lIHRvIGJlDQo+IGFub21hbG91cyBhbmQgc2hvdWxkIG5vdCBwcm9jZWVk IHVubGVzcyB0aGUgSUVTRyBzcGVjaWZpY2FsbHkgYWdyZWVzIHdpdGgNCj4gdGhpcyBhcHByb2Fj aC4gQWx0ZXJuYXRpdmVseSBSRkM1MjI2IGNvdWxkIGJlIGZ1cnRoZXIgcmV2aXNlZCB0bw0KPiBl eHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBndWlkZWxpbmVzIGFzIHRoZXkgcmVsYXRlIHRvIEV4cGVy aW1lbnRhbA0KPiBTcGVjaWZpY2F0aW9ucyAoYXMgZGlzdGluY3QgZnJvbSBleHBlcmltZW50YWwg YWxsb2NhdGlvbnMgd2l0aGluIFN0YW5kYXJkcw0KPiBUcmFjayBzcGVjaWZpY2F0aW9ucyksIGFz IHRoaXMgYXJlYSBhcHBlYXJzIHRvIGJlIHVuY2xlYXIgZnJvbSBteSByZWFkaW5nDQo+IG9mIFJG QzUyMjYuDQo+IA0KPiBIb3dldmVyIGl0IGlzIG5vdCBmb3IgbWUgdG8gcmVzb2x2ZSB0aGlzIGlz c3VlLCBub3IgaXMgaXQgdXAgdG8gdGhlIGRyYWZ0DQo+IGF1dGhvcnMsIG9yIHRoZSBMSVNQIHdv cmtpbmcgZ3JvdXAsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLiAgSXQgaXMgdXAgdG8gdGhlDQo+IElF U0cgYW5kDQo+IElBTkEgdG8gY2xhcmlmeSB0aGlzIHNpdHVhdGlvbiBhbmQgYWxsb3cgSUFOQSB0 byBiZSBnaXZlbiBjbGVhciBkaXJlY3Rpb25zDQo+IGFzIHRvIGhvdyB0byBtYWludGFpbiBwYXJh bWV0ZXIgcmVnaXN0cmllcyBmb3IgZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb25zDQo+IHdoaWxl IHRoZXkgcmVtYWluIGV4cGVyaW1lbnRzLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGxpc3AgbWFpbGluZyBsaXN0DQo+IGxpc3BA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQo= From nobody Mon Nov 28 05:59:32 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC361295AE; Mon, 28 Nov 2016 05:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R0qgjIKVCJC; Mon, 28 Nov 2016 05:59:28 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9A41294C5; Mon, 28 Nov 2016 05:59:28 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id EE7BE60235; Mon, 28 Nov 2016 14:59:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id A260318006E; Mon, 28 Nov 2016 14:59:26 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 14:59:26 +0100 From: To: Dino Farinacci , Geoff Huston Thread-Topic: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSSwvSGQwvHveDkym5s43SC04mqDtvm+AgAAa1YCAAJNP8A== Date: Mon, 28 Nov 2016 13:59:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB9287@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> In-Reply-To: <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 13:59:31 -0000 UmUtLA0KDQpXb3JrcyBmb3IgbWUsIHRvby4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBEaW5vIEZhcmluYWNjaSBbbWFpbHRvOmZhcmlu YWNjaUBnbWFpbC5jb21dDQo+IEVudm95w6nCoDogbHVuZGkgMjggbm92ZW1icmUgMjAxNiAwNzox MQ0KPiDDgMKgOiBHZW9mZiBIdXN0b24NCj4gQ2PCoDogSm9lbCBNLiBIYWxwZXJuOyBydGctZGly QGlldGYub3JnOyBaaGFuZ3hpYW4gKFhpYW4pOyBsaXNwQGlldGYub3JnOw0KPiBydGctYWRzQGll dGYub3JnOyBqb25hdGhhbi5oYXJkd2lja0BtZXRhc3dpdGNoLmNvbTsgZHJhZnQtaWV0Zi1saXNw LXR5cGUtDQo+IGlhbmEuYWxsQGlldGYub3JnOyBKb24gSHVkc29uDQo+IE9iamV0wqA6IFJlOiBb bGlzcF0gW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtbGlzcC10eXBlLWlhbmEt DQo+IDAzLnR4dA0KPiANCj4gSSB0aGluayB0aGlzIGlzIGEgZ29vZCBhbmQgZXhwZWRpZW50IHN1 Z2dlc3Rpb24uDQo+IA0KPiBEaW5vDQo+IA0KPiA+IE9uIE5vdiAyNywgMjAxNiwgYXQgODozNCBQ TSwgR2VvZmYgSHVzdG9uIDxnaWhAYXBuaWMubmV0PiB3cm90ZToNCj4gPg0KPiA+IEkgYW0gbm90 IGZ1bGx5IGF3YXJlIG9mIGFsbCB0aGUgb3B0aW9ucyBoZXJlLCBidXQgaXQgc3RyaWtlcyBtZSB0 aGF0IHRoZQ0KPiBJRVNHIGNvdWxkIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBFWFBFUklNRU5U QUwsIGNvbnNpc3RlbnQgd2l0aCBSRkM2ODMwLA0KPiBhbmQgaW4gdGhlIGZ1dHVyZSB3aGF0ZXZl ciBtZWNoYW5pc20gaXMgdXNlZCB0byB1cGRhdGUgUkZDNjgzMCB0bw0KPiBTdGFuZGFyZHMgVHJh Y2ssIHRoZSBzYW1lIGRvY3VtZW50IGNvdWxkIFVQREFURSB0aGlzIGRvY3VtZW50IGFuZCBwbGFj ZSBpdA0KPiBvbiB0aGUgc3RhbmRhcmRzIHRyYWNrIGJ5IHZpcnR1ZSBvZiB0aGUgVXBkYXRlLg0K PiA+DQo+ID4gVGhlcmUgbWF5IGJlIG90aGVyIGFwcHJvYWNoZXMgYXMgd2VsbCwgYXMgdGhpcyBp cyBfbm90XyBhbiBhcmVhIHdoZXJlIEkNCj4gd291bGQgY2FsbCBteXNlbGYgYW4g4oCcZXhwZXJ0 4oCdIQ0KPiA+DQo+ID4gcmVnYXJkcywNCj4gPg0KPiA+ICBHZW9mZg0KPiA+DQo+ID4NCj4gPg0K PiA+PiBPbiAyOCBOb3YuIDIwMTYsIGF0IDM6MDEgcG0sIEpvZWwgTS4gSGFscGVybiA8am1oQGpv ZWxoYWxwZXJuLmNvbT4NCj4gd3JvdGU6DQo+ID4+DQo+ID4+IFlvdSByYWlzZSBhbiBpbnRlcmVz dGluZyBwb2ludCBHZW9mZi4NCj4gPj4NCj4gPj4gVGhlIGRvY3VtZW50cyBhcmUgZXhwZXJpbWVu dGFsLiAgQXMgc3VjaCwgaXQgaXMgcmVhc29hbmJsZSBmb3IgdGhpcw0KPiBkb2N1bWVudCB0byBi ZSBleHBlcmltZW50YWwsIGFuZCBmb3IgaXQgbWVyZWx5IHRvIHJlcXVpcmUgSUVURiBSRkMgZm9y DQo+IGFzc2lnbm1lbnQsIHdpdGhvdXQgcmVzdHJpY3RpbmcgaXQgdG8gU3RhbmRhcmRzIFRyYWNr IFJGQ3MuDQo+ID4+DQo+ID4+IEFuZCB3aGlsZSB3ZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgbW92 aW5nIHRoZSBMSVNQIGRvY3VtZW50cyB0bw0KPiBTdGFuZGFyZHMgVHJhY2ssIHRoYXQgd2lsbCB0 YWtlIHRpbWUuDQo+ID4+DQo+ID4+IEhvd2V2ZXIsIEkgd291bGQgbGlrZSB0byBiZSBhYmxlIHRv IGhhdmUgdGhlIHJpZ2h0IHN0YXR1cyBpbiB0aGUNCj4gZG9jdW1lbnRzIHdoZW4gd2UgZ2V0IHRo ZSB1cGdyYWRlIGRvbmUuICBXZSBjYW4gZG8gYSByZXZpc2lvbiBvZiB0aGlzDQo+IGRvY3VtZW50 IGFzIHdlbGwsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIGNyZWF0aW5nIHdvcmsuDQo+ID4+DQo+ID4+ IEFueSBzdWdnZXN0aW9ucyBmb3IgaG93IHRvIHRocmVhZCB0aGlzIG5lZWRseT8NCj4gPj4NCj4g Pj4gWW91cnMsDQo+ID4+IEpvZWwNCj4gPj4NCj4gPj4+IE9uIDExLzI3LzE2IDEwOjA0IFBNLCBH ZW9mZiBIdXN0b24gd3JvdGU6DQo+ID4+PiBIZWxsbywNCj4gPj4+DQo+ID4+PiBJIGhhdmUgYmVl biBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcw0K PiBkcmFmdC4NCj4gPj4+DQo+ID4+PiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+ID4+PiBkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQNCj4gc29t ZXRpbWVzDQo+ID4+PiBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZp ZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlDQo+IHRvDQo+ID4+PiB0aGUgUm91dGluZyBBRHMu IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLA0KPiA+ Pj4gcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFj L3dpa2kvUnRnRGlyDQo+ID4+Pg0KPiA+Pj4gQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHBy aW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsDQo+IGl0DQo+ID4+PiB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90 aGVyIElFVEYNCj4gTGFzdA0KPiA+Pj4gQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBh bmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoDQo+ID4+PiBkaXNjdXNzaW9uIG9yIGJ5 IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gPj4+DQo+ID4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1s aXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gPj4+IFJldmlld2VyOiBHZW9mZiBIdXN0b24gUmV2aWV3 DQo+ID4+PiBEYXRlOiAyOCBOb3ZlbWJlciAyMDE2DQo+ID4+PiBJRVRGIExDIEVuZCBEYXRlOiBu b3QgY2FsbGVkDQo+ID4+PiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiA+Pj4N Cj4gPj4+IFN1bW1hcnk6DQo+ID4+Pg0KPiA+Pj4gSSBoYXZlIHNpZ25pZmljYW50IGNvbmNlcm5z IGFib3V0IHRoaXMgZG9jdW1lbnQgYW5kIHJlY29tbWVuZCB0aGF0IHRoZQ0KPiA+Pj4gUm91dGlu ZyBBRHMgZGlzY3VzcyB0aGVzZSBpc3N1ZXMgZnVydGhlciB3aXRoIHRoZSBhdXRob3JzIGFuZCB0 aGUNCj4gSUFOQS4NCj4gPj4+DQo+ID4+PiBDb21tZW50czoNCj4gPj4+DQo+ID4+PiBEcmFmdCBx dWFsaXR5IGFuZCByZWFkYWJpbGl0eS4NCj4gPj4+DQo+ID4+PiBUaGUgdGhpcmQgcGFyYWdyYXBo IG9mIHRoZSBJbnRyb2R1Y3Rpb24gaXMgdW5jbGVhci4gR2l2ZW4gdGhhdCBMSVNQDQo+IGl0c2Vs Zg0KPiA+Pj4gaXMgYW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb24gaXQgaXMgaGFyZCB0byB1 bmRlcnN0YW5kIHRoZQ0KPiBkaXN0aW5jdGlvbg0KPiA+Pj4gYmVpbmcgbWFkZSBiZXR3ZWVuIHRo ZSAiZXhwZXJpbWVudGF0aW9uIHB1cnBvc2VzIiBhbmQgc29tZSBvdGhlcg0KPiA+Pj4gdW5kZXNj cmliZWQgcHVycG9zZSB3aGljaCB0aGlzIHJldmlld2VyIGNhbiBvbmx5IGNvbmNsdWRlIGlzIGFs c28gYW4NCj4gPj4+IGV4cGVyaW1lbnRhdGlvbiBwdXJwb3NlLiBJIHN1Z2dlc3QgcmUtdGhpbmtp bmcgdGhlIGludGVudCBvZiB0aGlzDQo+ID4+PiBwYXJhZ3JhcGggYW5kIGV4cHJlc3NpbmcgaXQg aW4gc2ltcGxlciB0ZXJtcy4NCj4gPj4+DQo+ID4+PiBJbiBzZWN0aW9uIDIsIHRoZSB1c2Ugb2Yg dGhlIG5vcm1hdGl2ZSAiTVVTVCIgc2VlbXMgdG8gYmUNCj4gaW5hcHByb3ByaWF0ZSwNCj4gPj4+ IHBhcnRpY3VsYXJseSB3aGVuIGEgbm9uLW5vcm1hdGl2ZSAibXVzdCIgaXVzIHVzZWQgaW4gc2Vj dGlvbiA0IGluIGFuDQo+ID4+PiBpZGVudGljYWwgY29udGV4dC4NCj4gPj4+DQo+ID4+PiBNYWpv ciBJc3N1ZXM6DQo+ID4+Pg0KPiA+Pj4gSXQgc2VlbXMgYW5vbWFsb3VzIHRvIG1lIHRoYXQgYSBy ZXF1ZXN0IHRvIHNldCB1cCBhbiBJQU5BIFJlZ2lzdHJ5IGZvcg0KPiBhbg0KPiA+Pj4gRXhwZXJp bWVudGFsIFByb3RvY29sIChSRkM2ODMwIGlzIEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHByb3Bv c2VkIHRvDQo+IGJlIGENCj4gPj4+IFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudC4NCj4gPj4+DQo+ ID4+PiBGdXJ0aGVybW9yZSwgdGhlIGRvY3VtZW50IHN0YXRlcyB0aGF0IGFkZGl0aW9uYWwgdmFs dWVzIGJlIGFzc2lnbmVkDQo+IHZpYSBhDQo+ID4+PiBTdGFuZGFyZHMgQWN0aW9uLiBBZ2Fpbiwg aXQgYXBwZWFycyBhbm9tYWxvdXMgdG8gbWUgdGhhdCBhDQo+IHNwZWNpZmljYXRpb24NCj4gPj4+ IG9mIGEgcGFyYW1ldGVyIHZhbHVlIG9mIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCBiZSBkZXNj cmliZWQgYnkgYQ0KPiA+Pj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbi4NCj4gPj4+DQo+ID4+PiBJ ZiBSRkM2ODMwIGlzIHJldmlzZWQgYW5kIGlzIHJlLXB1Ymxpc2hlZCBhcyBhIFN0YW5kYXJkcyBU cmFjaw0KPiA+Pj4gc3BlY2lmaWNhdGlvbiB0aGVuIHRoZXNlIHBvaW50cyBhcmUgb2YgY291cnNl IG5vdCByZWxldmFudCwgYnV0IHVudGlsDQo+IHN1Y2gNCj4gPj4+IGEgcHVibGljYXRpb24gdGFr ZXMgcGxhY2UsIHNwZWNpZnlpbmcgYW4gSUFOQSBwYXJhbWV0ZXIgcmVnaXN0cnkgYXMgYQ0KPiA+ Pj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhwZXJpbWVudGFsIHByb3RvY29sIHNl ZW1zIHRvIG1lIHRvIGJlDQo+ID4+PiBhbm9tYWxvdXMgYW5kIHNob3VsZCBub3QgcHJvY2VlZCB1 bmxlc3MgdGhlIElFU0cgc3BlY2lmaWNhbGx5IGFncmVlcw0KPiB3aXRoDQo+ID4+PiB0aGlzIGFw cHJvYWNoLiBBbHRlcm5hdGl2ZWx5IFJGQzUyMjYgY291bGQgYmUgZnVydGhlciByZXZpc2VkIHRv DQo+ID4+PiBleHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBndWlkZWxpbmVzIGFzIHRoZXkgcmVsYXRl IHRvIEV4cGVyaW1lbnRhbA0KPiA+Pj4gU3BlY2lmaWNhdGlvbnMgKGFzIGRpc3RpbmN0IGZyb20g ZXhwZXJpbWVudGFsIGFsbG9jYXRpb25zIHdpdGhpbg0KPiBTdGFuZGFyZHMNCj4gPj4+IFRyYWNr IHNwZWNpZmljYXRpb25zKSwgYXMgdGhpcyBhcmVhIGFwcGVhcnMgdG8gYmUgdW5jbGVhciBmcm9t IG15DQo+IHJlYWRpbmcNCj4gPj4+IG9mIFJGQzUyMjYuDQo+ID4+Pg0KPiA+Pj4gSG93ZXZlciBp dCBpcyBub3QgZm9yIG1lIHRvIHJlc29sdmUgdGhpcyBpc3N1ZSwgbm9yIGlzIGl0IHVwIHRvIHRo ZQ0KPiBkcmFmdA0KPiA+Pj4gYXV0aG9ycywgb3IgdGhlIExJU1Agd29ya2luZyBncm91cCwgYXMg ZmFyIGFzIEkgY2FuIHRlbGwuICBJdCBpcyB1cCB0bw0KPiB0aGUgSUVTRyBhbmQNCj4gPj4+IElB TkEgdG8gY2xhcmlmeSB0aGlzIHNpdHVhdGlvbiBhbmQgYWxsb3cgSUFOQSB0byBiZSBnaXZlbiBj bGVhcg0KPiBkaXJlY3Rpb25zDQo+ID4+PiBhcyB0byBob3cgdG8gbWFpbnRhaW4gcGFyYW1ldGVy IHJlZ2lzdHJpZXMgZm9yIGV4cGVyaW1lbnRhbA0KPiBzcGVjaWZpY2F0aW9ucw0KPiA+Pj4gd2hp bGUgdGhleSByZW1haW4gZXhwZXJpbWVudHMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGxp c3AgbWFpbGluZyBsaXN0DQo+ID4gbGlzcEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0K From nobody Mon Nov 28 06:05:10 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8888A1295A3; Mon, 28 Nov 2016 06:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYz2JM79jqyX; Mon, 28 Nov 2016 06:05:08 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E64129483; Mon, 28 Nov 2016 06:05:07 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 80D2860324; Mon, 28 Nov 2016 15:05:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 30EBF8006A; Mon, 28 Nov 2016 15:05:06 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0319.002; Mon, 28 Nov 2016 15:05:00 +0100 From: To: BOUCADAIR Mohamed IMT/OLN , Dino Farinacci , Geoff Huston Thread-Topic: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSSwvUUj9ILWswkWoprVxl0cx6KDtvm+AgAAa1YCAAILhgIAAEh8Q Date: Mon, 28 Nov 2016 14:04:56 +0000 Message-ID: <17824_1480341906_583C3992_17824_11501_1_118c2c10-9fa0-45c2-a15a-5819f01a3972@OPEXCLILM6C.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <652FECD2-E034-4A21-86F8-DADA903A700B@gmail.com> <787AE7BB302AE849A7480A190F8B933009DB9287@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB9287@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [lisp] [RTG-DIR] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 14:05:09 -0000 SGksDQoNCkdlb2ZmJ3MgcHJvcG9zYWwgaXMgYWxzbyBmaW5lIGJ5IG1lLg0KDQpDaGVlcnMsDQoN CkNocmlzdGlhbi4NCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIFttYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bV0gDQpFbnZvecOpwqA6IGx1bmRpIDI4IG5vdmVtYnJlIDIwMTYgMTQ6NTkNCsOAwqA6IERpbm8g RmFyaW5hY2NpOyBHZW9mZiBIdXN0b24NCkNjwqA6IEpvZWwgTS4gSGFscGVybjsgcnRnLWRpckBp ZXRmLm9yZzsgWmhhbmd4aWFuIChYaWFuKTsgbGlzcEBpZXRmLm9yZzsgcnRnLWFkc0BpZXRmLm9y Zzsgam9uYXRoYW4uaGFyZHdpY2tAbWV0YXN3aXRjaC5jb207IGRyYWZ0LWlldGYtbGlzcC10eXBl LWlhbmEuYWxsQGlldGYub3JnOyBKb24gSHVkc29uDQpPYmpldMKgOiBSRTogW2xpc3BdIFtSVEct RElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLTAzLnR4dA0KDQpS ZS0sDQoNCldvcmtzIGZvciBtZSwgdG9vLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERpbm8gRmFyaW5hY2NpIFttYWlsdG86ZmFyaW5h Y2NpQGdtYWlsLmNvbV0gRW52b3nDqcKgOiBsdW5kaSAyOCANCj4gbm92ZW1icmUgMjAxNiAwNzox MSDDgMKgOiBHZW9mZiBIdXN0b24gQ2PCoDogSm9lbCBNLiBIYWxwZXJuOyANCj4gcnRnLWRpckBp ZXRmLm9yZzsgWmhhbmd4aWFuIChYaWFuKTsgbGlzcEBpZXRmLm9yZzsgcnRnLWFkc0BpZXRmLm9y ZzsgDQo+IGpvbmF0aGFuLmhhcmR3aWNrQG1ldGFzd2l0Y2guY29tOyBkcmFmdC1pZXRmLWxpc3At dHlwZS0gDQo+IGlhbmEuYWxsQGlldGYub3JnOyBKb24gSHVkc29uIE9iamV0wqA6IFJlOiBbbGlz cF0gW1JURy1ESVJdIFJ0Z0RpciANCj4gcmV2aWV3OiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5h LSAwMy50eHQNCj4gDQo+IEkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgYW5kIGV4cGVkaWVudCBzdWdn ZXN0aW9uLg0KPiANCj4gRGlubw0KPiANCj4gPiBPbiBOb3YgMjcsIDIwMTYsIGF0IDg6MzQgUE0s IEdlb2ZmIEh1c3RvbiA8Z2loQGFwbmljLm5ldD4gd3JvdGU6DQo+ID4NCj4gPiBJIGFtIG5vdCBm dWxseSBhd2FyZSBvZiBhbGwgdGhlIG9wdGlvbnMgaGVyZSwgYnV0IGl0IHN0cmlrZXMgbWUgdGhh dCANCj4gPiB0aGUNCj4gSUVTRyBjb3VsZCBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgRVhQRVJJ TUVOVEFMLCBjb25zaXN0ZW50IHdpdGggDQo+IFJGQzY4MzAsIGFuZCBpbiB0aGUgZnV0dXJlIHdo YXRldmVyIG1lY2hhbmlzbSBpcyB1c2VkIHRvIHVwZGF0ZSANCj4gUkZDNjgzMCB0byBTdGFuZGFy ZHMgVHJhY2ssIHRoZSBzYW1lIGRvY3VtZW50IGNvdWxkIFVQREFURSB0aGlzIA0KPiBkb2N1bWVu dCBhbmQgcGxhY2UgaXQgb24gdGhlIHN0YW5kYXJkcyB0cmFjayBieSB2aXJ0dWUgb2YgdGhlIFVw ZGF0ZS4NCj4gPg0KPiA+IFRoZXJlIG1heSBiZSBvdGhlciBhcHByb2FjaGVzIGFzIHdlbGwsIGFz IHRoaXMgaXMgX25vdF8gYW4gYXJlYSANCj4gPiB3aGVyZSBJDQo+IHdvdWxkIGNhbGwgbXlzZWxm IGFuIOKAnGV4cGVydOKAnSENCj4gPg0KPiA+IHJlZ2FyZHMsDQo+ID4NCj4gPiAgR2VvZmYNCj4g Pg0KPiA+DQo+ID4NCj4gPj4gT24gMjggTm92LiAyMDE2LCBhdCAzOjAxIHBtLCBKb2VsIE0uIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+PiBZb3UgcmFp c2UgYW4gaW50ZXJlc3RpbmcgcG9pbnQgR2VvZmYuDQo+ID4+DQo+ID4+IFRoZSBkb2N1bWVudHMg YXJlIGV4cGVyaW1lbnRhbC4gIEFzIHN1Y2gsIGl0IGlzIHJlYXNvYW5ibGUgZm9yIHRoaXMNCj4g ZG9jdW1lbnQgdG8gYmUgZXhwZXJpbWVudGFsLCBhbmQgZm9yIGl0IG1lcmVseSB0byByZXF1aXJl IElFVEYgUkZDIGZvciANCj4gYXNzaWdubWVudCwgd2l0aG91dCByZXN0cmljdGluZyBpdCB0byBT dGFuZGFyZHMgVHJhY2sgUkZDcy4NCj4gPj4NCj4gPj4gQW5kIHdoaWxlIHdlIGFyZSBpbiB0aGUg cHJvY2VzcyBvZiBtb3ZpbmcgdGhlIExJU1AgZG9jdW1lbnRzIHRvDQo+IFN0YW5kYXJkcyBUcmFj aywgdGhhdCB3aWxsIHRha2UgdGltZS4NCj4gPj4NCj4gPj4gSG93ZXZlciwgSSB3b3VsZCBsaWtl IHRvIGJlIGFibGUgdG8gaGF2ZSB0aGUgcmlnaHQgc3RhdHVzIGluIHRoZQ0KPiBkb2N1bWVudHMg d2hlbiB3ZSBnZXQgdGhlIHVwZ3JhZGUgZG9uZS4gIFdlIGNhbiBkbyBhIHJldmlzaW9uIG9mIHRo aXMgDQo+IGRvY3VtZW50IGFzIHdlbGwsIGJ1dCB0aGF0IHNlZW1zIHRvIGJlIGNyZWF0aW5nIHdv cmsuDQo+ID4+DQo+ID4+IEFueSBzdWdnZXN0aW9ucyBmb3IgaG93IHRvIHRocmVhZCB0aGlzIG5l ZWRseT8NCj4gPj4NCj4gPj4gWW91cnMsDQo+ID4+IEpvZWwNCj4gPj4NCj4gPj4+IE9uIDExLzI3 LzE2IDEwOjA0IFBNLCBHZW9mZiBIdXN0b24gd3JvdGU6DQo+ID4+PiBIZWxsbywNCj4gPj4+DQo+ ID4+PiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZp ZXdlciBmb3IgdGhpcw0KPiBkcmFmdC4NCj4gPj4+DQo+ID4+PiBUaGUgUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3IgDQo+ID4+PiByb3V0aW5nLXJlbGF0 ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCANCj4gPj4+ IElFU0cgcmV2aWV3LCBhbmQNCj4gc29tZXRpbWVzDQo+ID4+PiBvbiBzcGVjaWFsIHJlcXVlc3Qu IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSANCj4gPj4+IGFzc2lzdGFu Y2UNCj4gdG8NCj4gPj4+IHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIFJvdXRpbmcgDQo+ID4+PiBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSANCj4gPj4+IOKA i2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4g Pj4+DQo+ID4+PiBBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIA0KPiA+Pj4gQURzLA0KPiBpdA0KPiA+Pj4gd291bGQgYmUgaGVs cGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciANCj4g Pj4+IElFVEYNCj4gTGFzdA0KPiA+Pj4gQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBh bmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIA0KPiA+Pj4gZGlzY3Vzc2lvbiBvciBi eSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYt bGlzcC10eXBlLWlhbmEtMDMudHh0DQo+ID4+PiBSZXZpZXdlcjogR2VvZmYgSHVzdG9uIFJldmll dw0KPiA+Pj4gRGF0ZTogMjggTm92ZW1iZXIgMjAxNg0KPiA+Pj4gSUVURiBMQyBFbmQgRGF0ZTog bm90IGNhbGxlZA0KPiA+Pj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCj4gPj4+ DQo+ID4+PiBTdW1tYXJ5Og0KPiA+Pj4NCj4gPj4+IEkgaGF2ZSBzaWduaWZpY2FudCBjb25jZXJu cyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQgdGhhdCANCj4gPj4+IHRoZSBSb3V0 aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlzc3VlcyBmdXJ0aGVyIHdpdGggdGhlIGF1dGhvcnMgYW5k IA0KPiA+Pj4gdGhlDQo+IElBTkEuDQo+ID4+Pg0KPiA+Pj4gQ29tbWVudHM6DQo+ID4+Pg0KPiA+ Pj4gRHJhZnQgcXVhbGl0eSBhbmQgcmVhZGFiaWxpdHkuDQo+ID4+Pg0KPiA+Pj4gVGhlIHRoaXJk IHBhcmFncmFwaCBvZiB0aGUgSW50cm9kdWN0aW9uIGlzIHVuY2xlYXIuIEdpdmVuIHRoYXQgDQo+ ID4+PiBMSVNQDQo+IGl0c2VsZg0KPiA+Pj4gaXMgYW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRp b24gaXQgaXMgaGFyZCB0byB1bmRlcnN0YW5kIHRoZQ0KPiBkaXN0aW5jdGlvbg0KPiA+Pj4gYmVp bmcgbWFkZSBiZXR3ZWVuIHRoZSAiZXhwZXJpbWVudGF0aW9uIHB1cnBvc2VzIiBhbmQgc29tZSBv dGhlciANCj4gPj4+IHVuZGVzY3JpYmVkIHB1cnBvc2Ugd2hpY2ggdGhpcyByZXZpZXdlciBjYW4g b25seSBjb25jbHVkZSBpcyBhbHNvIA0KPiA+Pj4gYW4gZXhwZXJpbWVudGF0aW9uIHB1cnBvc2Uu IEkgc3VnZ2VzdCByZS10aGlua2luZyB0aGUgaW50ZW50IG9mIA0KPiA+Pj4gdGhpcyBwYXJhZ3Jh cGggYW5kIGV4cHJlc3NpbmcgaXQgaW4gc2ltcGxlciB0ZXJtcy4NCj4gPj4+DQo+ID4+PiBJbiBz ZWN0aW9uIDIsIHRoZSB1c2Ugb2YgdGhlIG5vcm1hdGl2ZSAiTVVTVCIgc2VlbXMgdG8gYmUNCj4g aW5hcHByb3ByaWF0ZSwNCj4gPj4+IHBhcnRpY3VsYXJseSB3aGVuIGEgbm9uLW5vcm1hdGl2ZSAi bXVzdCIgaXVzIHVzZWQgaW4gc2VjdGlvbiA0IGluIA0KPiA+Pj4gYW4gaWRlbnRpY2FsIGNvbnRl eHQuDQo+ID4+Pg0KPiA+Pj4gTWFqb3IgSXNzdWVzOg0KPiA+Pj4NCj4gPj4+IEl0IHNlZW1zIGFu b21hbG91cyB0byBtZSB0aGF0IGEgcmVxdWVzdCB0byBzZXQgdXAgYW4gSUFOQSBSZWdpc3RyeSAN Cj4gPj4+IGZvcg0KPiBhbg0KPiA+Pj4gRXhwZXJpbWVudGFsIFByb3RvY29sIChSRkM2ODMwIGlz IEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHByb3Bvc2VkIA0KPiA+Pj4gdG8NCj4gYmUgYQ0KPiA+ Pj4gU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50Lg0KPiA+Pj4NCj4gPj4+IEZ1cnRoZXJtb3JlLCB0 aGUgZG9jdW1lbnQgc3RhdGVzIHRoYXQgYWRkaXRpb25hbCB2YWx1ZXMgYmUgDQo+ID4+PiBhc3Np Z25lZA0KPiB2aWEgYQ0KPiA+Pj4gU3RhbmRhcmRzIEFjdGlvbi4gQWdhaW4sIGl0IGFwcGVhcnMg YW5vbWFsb3VzIHRvIG1lIHRoYXQgYQ0KPiBzcGVjaWZpY2F0aW9uDQo+ID4+PiBvZiBhIHBhcmFt ZXRlciB2YWx1ZSBvZiBhbiBleHBlcmltZW50YWwgcHJvdG9jb2wgYmUgZGVzY3JpYmVkIGJ5IGEg DQo+ID4+PiBTdGFuZGFyZHMgVHJhY2sgYWN0aW9uLg0KPiA+Pj4NCj4gPj4+IElmIFJGQzY4MzAg aXMgcmV2aXNlZCBhbmQgaXMgcmUtcHVibGlzaGVkIGFzIGEgU3RhbmRhcmRzIFRyYWNrIA0KPiA+ Pj4gc3BlY2lmaWNhdGlvbiB0aGVuIHRoZXNlIHBvaW50cyBhcmUgb2YgY291cnNlIG5vdCByZWxl dmFudCwgYnV0IA0KPiA+Pj4gdW50aWwNCj4gc3VjaA0KPiA+Pj4gYSBwdWJsaWNhdGlvbiB0YWtl cyBwbGFjZSwgc3BlY2lmeWluZyBhbiBJQU5BIHBhcmFtZXRlciByZWdpc3RyeSANCj4gPj4+IGFz IGEgU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhwZXJpbWVudGFsIHByb3RvY29sIHNl ZW1zIHRvIA0KPiA+Pj4gbWUgdG8gYmUgYW5vbWFsb3VzIGFuZCBzaG91bGQgbm90IHByb2NlZWQg dW5sZXNzIHRoZSBJRVNHIA0KPiA+Pj4gc3BlY2lmaWNhbGx5IGFncmVlcw0KPiB3aXRoDQo+ID4+ PiB0aGlzIGFwcHJvYWNoLiBBbHRlcm5hdGl2ZWx5IFJGQzUyMjYgY291bGQgYmUgZnVydGhlciBy ZXZpc2VkIHRvIA0KPiA+Pj4gZXhwbGljaXRseSBkZXNjcmliZSB0aGUgZ3VpZGVsaW5lcyBhcyB0 aGV5IHJlbGF0ZSB0byBFeHBlcmltZW50YWwgDQo+ID4+PiBTcGVjaWZpY2F0aW9ucyAoYXMgZGlz dGluY3QgZnJvbSBleHBlcmltZW50YWwgYWxsb2NhdGlvbnMgd2l0aGluDQo+IFN0YW5kYXJkcw0K PiA+Pj4gVHJhY2sgc3BlY2lmaWNhdGlvbnMpLCBhcyB0aGlzIGFyZWEgYXBwZWFycyB0byBiZSB1 bmNsZWFyIGZyb20gbXkNCj4gcmVhZGluZw0KPiA+Pj4gb2YgUkZDNTIyNi4NCj4gPj4+DQo+ID4+ PiBIb3dldmVyIGl0IGlzIG5vdCBmb3IgbWUgdG8gcmVzb2x2ZSB0aGlzIGlzc3VlLCBub3IgaXMg aXQgdXAgdG8gDQo+ID4+PiB0aGUNCj4gZHJhZnQNCj4gPj4+IGF1dGhvcnMsIG9yIHRoZSBMSVNQ IHdvcmtpbmcgZ3JvdXAsIGFzIGZhciBhcyBJIGNhbiB0ZWxsLiAgSXQgaXMgDQo+ID4+PiB1cCB0 bw0KPiB0aGUgSUVTRyBhbmQNCj4gPj4+IElBTkEgdG8gY2xhcmlmeSB0aGlzIHNpdHVhdGlvbiBh bmQgYWxsb3cgSUFOQSB0byBiZSBnaXZlbiBjbGVhcg0KPiBkaXJlY3Rpb25zDQo+ID4+PiBhcyB0 byBob3cgdG8gbWFpbnRhaW4gcGFyYW1ldGVyIHJlZ2lzdHJpZXMgZm9yIGV4cGVyaW1lbnRhbA0K PiBzcGVjaWZpY2F0aW9ucw0KPiA+Pj4gd2hpbGUgdGhleSByZW1haW4gZXhwZXJpbWVudHMuDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4gbGlzcEBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNj ZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Nov 28 10:54:43 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C19129F8F for ; Mon, 28 Nov 2016 10:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.398 X-Spam-Level: X-Spam-Status: No, score=-108.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmFFBIs1y7Zq for ; Mon, 28 Nov 2016 10:54:39 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A950A129F8B for ; Mon, 28 Nov 2016 10:54:38 -0800 (PST) Received: from iamda3.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon) with ESMTPS id 10fcd6d5-b59c-11e6-b8ce-005056b6ee6f; Tue, 29 Nov 2016 04:54:19 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Nov 2016 04:54:28 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 29 Nov 2016 05:54:25 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <46143E39-F8EF-4E41-8893-C166FF5F8C5E@apnic.net> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 18:54:42 -0000 You appear to have misunderstood me - its _not_ that this draft seeks to = create an IANA registry for an experimental specification that I found to be = anomalous. What=20 I found anomalous was that the document proposing such an action was = itself proposed=20 to be a Standards Track document.=20 Clear now? thanks, Geoff > On 29 Nov. 2016, at 12:43 am, = wrote: >=20 > Hi Goeff,=20 >=20 > I have one comment about this part of your review:=20 >=20 >> It seems anomalous to me that a request to set up an IANA Registry = for an >> Experimental Protocol (RFC6830 is Experimental) is itself proposed to = be a >> Standards Track document. >=20 > FWIW, I'm aware of an IANA registry for an experimental protocol that = you can check here:=20 > = http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#mptcp-= option-subtypes=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : lisp [mailto:lisp-bounces@ietf.org] De la part de Geoff Huston >> Envoy=C3=A9 : lundi 28 novembre 2016 04:04 >> =C3=80 : Zhangxian (Xian); rtg-ads@ietf.org >> Cc : rtg-dir@ietf.org; lisp@ietf.org; = jonathan.hardwick@metaswitch.com; >> draft-ietf-lisp-type-iana.all@ietf.org; Jon Hudson >> Objet : [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. >>=20 >> The Routing Directorate seeks to review all routing or = routing-related >> drafts as they pass through IETF last call and IESG review, and = sometimes >> on special request. The purpose of the review is to provide = assistance to >> the Routing ADs. For more information about the Routing Directorate, >> please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it >> would be helpful if you could consider them along with any other IETF = Last >> Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >>=20 >> Document: draft-ietf-lisp-type-iana-03.txt >> Reviewer: Geoff Huston Review >> Date: 28 November 2016 >> IETF LC End Date: not called >> Intended Status: Standards Track >>=20 >> Summary: >>=20 >> I have significant concerns about this document and recommend that = the >> Routing ADs discuss these issues further with the authors and the = IANA. >>=20 >> Comments: >>=20 >> Draft quality and readability. >>=20 >> The third paragraph of the Introduction is unclear. Given that LISP = itself >> is an experimental specification it is hard to understand the = distinction >> being made between the "experimentation purposes" and some other >> undescribed purpose which this reviewer can only conclude is also an >> experimentation purpose. I suggest re-thinking the intent of this >> paragraph and expressing it in simpler terms. >>=20 >> In section 2, the use of the normative "MUST" seems to be = inappropriate, >> particularly when a non-normative "must" ius used in section 4 in an >> identical context. >>=20 >> Major Issues: >>=20 >> It seems anomalous to me that a request to set up an IANA Registry = for an >> Experimental Protocol (RFC6830 is Experimental) is itself proposed to = be a >> Standards Track document. >>=20 >> Furthermore, the document states that additional values be assigned = via a >> Standards Action. Again, it appears anomalous to me that a = specification >> of a parameter value of an experimental protocol be described by a >> Standards Track action. >>=20 >> If RFC6830 is revised and is re-published as a Standards Track >> specification then these points are of course not relevant, but until = such >> a publication takes place, specifying an IANA parameter registry as a >> Standards Track action for an experimental protocol seems to me to be >> anomalous and should not proceed unless the IESG specifically agrees = with >> this approach. Alternatively RFC5226 could be further revised to >> explicitly describe the guidelines as they relate to Experimental >> Specifications (as distinct from experimental allocations within = Standards >> Track specifications), as this area appears to be unclear from my = reading >> of RFC5226. >>=20 >> However it is not for me to resolve this issue, nor is it up to the = draft >> authors, or the LISP working group, as far as I can tell. It is up = to the >> IESG and >> IANA to clarify this situation and allow IANA to be given clear = directions >> as to how to maintain parameter registries for experimental = specifications >> while they remain experiments. >>=20 >>=20 >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp From nobody Mon Nov 28 11:36:58 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A861294F9; Mon, 28 Nov 2016 11:36:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148036181375.5458.10572050248604275969.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 11:36:53 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-lcaf-22.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 19:36:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol of the IETF. Title : LISP Canonical Address Format (LCAF) Authors : Dino Farinacci Dave Meyer Job Snijders Filename : draft-ietf-lisp-lcaf-22.txt Pages : 47 Date : 2016-11-28 Abstract: This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-lcaf-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-lcaf-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 28 11:40:01 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C0129F9D; Mon, 28 Nov 2016 11:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOiUqgxcR3F8; Mon, 28 Nov 2016 11:39:56 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B8A129F4C; Mon, 28 Nov 2016 11:39:56 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id p66so13939014pga.2; Mon, 28 Nov 2016 11:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5zEWyiY8OaCH7DOIcCHEnIniFxvJUz3LelCeltEsxOc=; b=YcNrcgxrLgjafGtdR/kfGatb+zwMO1uqHfgv1h8dAw7IfOa/EwsL9SiYeOs8cfKKS6 5Ws/oMQj7r/yxiOObrB7S6PtLP+C6ejjv/JR/GP3tF9j2rWq0XeO2UDv15o+VS51j5qt mVw4MK9E/7kM/aBWwCk1Yr4duydAAxhin2ljr7940mhQy1mh6bSw4Xu3QD3Ok4v29uzo bm9huNJ9ImHjARis8mnhYEWcmbjBGlWZhb0/ci/1r6OOS5S47YWrIMXK2nw6tQwUzo/4 vs44EjK/9fCDTMS7eVWDzUPMBmaz87HEZTat19jgXz91GIYVWnxdn/aj6/KlufNaekXx hFUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5zEWyiY8OaCH7DOIcCHEnIniFxvJUz3LelCeltEsxOc=; b=DnS/UvhR0bUYhd9GUX2jnrzXkprmihb+Ebrg8gKUyQcWPvkyHXYUTqz3++XLDjhdLp 0CwlHk8iGyTnS2k4Q8s42wxrosAr2wo6PRZiqNwP5+zN20vLwk6BD0XwXNFGRvQZzjW1 9nrwtwtmRbH8ka4Yc4uAvBoXjLjJlsKRHniPYI/BOwJze7RNB7+lUXunLxFJWuKIDMKs EPnKujNkFrNKxZWalAFhQhZBVz/YfEpMRvsPIPLPhf8HdTj2CwZFUDGcu6s9zmjR49bX 3Y4Kd1JERYfZRFnOC5CPz1aAHzRTOnYXDsnSfYu27i1ZApwQhudQ7VsTI5KAV5wY4tyM JRvQ== X-Gm-Message-State: AKaTC035YMX05uzDIZjtamLDVgFX9gth1Ktz+ivqFX+nb4EprutHe7yu7bGv7ATUb8yLTg== X-Received: by 10.99.96.85 with SMTP id u82mr43223826pgb.47.1480361996115; Mon, 28 Nov 2016 11:39:56 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id s3sm89155089pfe.27.2016.11.28.11.39.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 11:39:55 -0800 (PST) From: Dino Farinacci Message-Id: <83C94329-AFE2-46AE-AA0A-EF571CA89E95@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_898C72A4-2300-48DF-960B-28E8BB6522FF" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Mon, 28 Nov 2016 11:39:47 -0800 In-Reply-To: <1515BC7D-0E24-4278-9529-6BE41F7336C1@gmail.com> To: Stephen Farrell References: <147636391150.3004.8744692629400023314.idtracker@ietfa.amsl.com> <05301FBB-A11C-4709-8659-CE347E03AFB3@gmail.com> <5b931a61-0c74-7045-ab1e-f240d762bde3@cs.tcd.ie> <1515BC7D-0E24-4278-9529-6BE41F7336C1@gmail.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: lisp-chairs@ietf.org, draft-ietf-lisp-lcaf@ietf.org, LISP mailing list list , The IESG Subject: Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 19:39:59 -0000 --Apple-Mail=_898C72A4-2300-48DF-960B-28E8BB6522FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Stephen for your careful review. I=E2=80=99ve updated the draft = to clarify your concerns. Let me know if there is any remaining item = preventing clearing of your discuss. And thanks Deborah for your = contributions. You can find a new submitted draft-ietf-lisp-lcaf-22 and a diff file = enclosed. Thanks again, Dino --Apple-Mail=_898C72A4-2300-48DF-960B-28E8BB6522FF Content-Disposition: attachment; filename=rfcdiff-lcaf.html Content-Type: text/html; x-unix-mode=0644; name="rfcdiff-lcaf.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-lcaf-21.txt - = draft-ietf-lisp-lcaf-22.txt=20 =20 =20 =20 =20 =20 =20= = =
< draft-ietf-lisp-lcaf-21.txt  =  draft-ietf-lisp-lcaf-22.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental D. Meyer = Intended status: Experimental = D. Meyer
Expires: May 20, 2017 = Brocade Expires: June 1, 2017 = Brocade
= J. Snijders = J. Snijders
= NTT Communications = = NTT
= November 16, 2016 = November 28, 2016
=
= LISP Canonical Address Format (LCAF) = LISP Canonical Address Format (LCAF)
= draft-ietf-lisp-lcaf-21 = = draft-ietf-lisp-lcaf-22
=
Abstract = Abstract
=
This draft defines a canonical address format = encoding used in LISP This document defines a canonical address format = encoding used in
control = messages and in the encoding of lookup keys for the LISP = LISP control messages and in the encoding = of lookup keys for the LISP
Mapping = Database System. Mapping Database = System.
=
Requirements = Language Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
"SHOULD", = "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = "SHOULD", "SHOULD NOT", "RECOMMENDED", = "MAY", and "OPTIONAL" in this
document are = to be interpreted as described in [RFC2119]. document are to be interpreted as described in = [RFC2119].
=
Status of This = Memo Status of This Memo
=
=
skipping to = change at = page 1, line 41 =C2=B6 = skipping to change at page 1, line 41 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on May 20, = 2017. This Internet-Draft will = expire on June 1, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 17 =C2=B6 = skipping to change at page 2, line 17 =C2=B6
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
described in = the Simplified BSD License. = described in the Simplified BSD License.
=
Table of = Contents Table of Contents
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
3. LISP = Canonical Address Format Encodings . . . . . . . . . . . 5 = 3. LISP Canonical Address Format Encodings = . . . . . . . . . . . 5
4. LISP = Canonical Address Applications . . . . . . . . . . . . . 7 4. LISP = Canonical Address Applications . . . . . . . . . . . . . 8
4.1. = Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.1. = Segmentation using LISP . . . . . . . . . . . . . . . . . 8
4.2. = Carrying AS Numbers in the Mapping Database . . . . . . . 9 = 4.2. Carrying AS Numbers in the Mapping = Database . . . . . . . 9
4.3. = Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.3. = Assigning Geo Coordinates to Locator Addresses . . . . . 11
4.4. NAT = Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.4. = NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13
4.5. = Multicast Group Membership Information . . . . . . . . . 14 4.5. = Multicast Group Membership Information . . . . . . . . . 15
4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 17
4.7. = Storing Security Data in the Mapping Database . . . . . . 17 4.7. = Storing Security Data in the Mapping Database . . . . . . 18
4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 20
4.9. = Replication List Entries for Multicast Forwarding . . . . 21 4.9. = Replication List Entries for Multicast Forwarding . . . . 22
4.10. = Applications for AFI List Type . . . . . . . . . . . . . 22 4.10. = Applications for AFI List Type . . . . . . . . . . . . . 23
4.10.1. = Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 = 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 23
4.10.2. = Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 = 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 24
4.10.3. = ASCII Names in the Mapping Database . . . . . . . . 24 = 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 25
4.10.4. = Using Recursive LISP Canonical Address Encodings . . 25 = 4.10.4. Using Recursive LISP Canonical Address Encodings . . 26
4.10.5. = Compatibility Mode Use Case . . . . . . . . . . . . 26 = 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 27
5. = Experimental LISP Canonical Address Applications . . . . . . 27 5. = Experimental LISP Canonical Address Applications . . . . . . 28
5.1. = Convey Application Specific Data . . . . . . . . . . . . 27 5.1. = Convey Application Specific Data . . . . . . . . . . . . 29
5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 29 5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 30
5.3. PETR = Admission Control Functionality . . . . . . . . . . 30 5.3. = PETR Admission Control Functionality . . . . . . . . . . 32
5.4. Data = Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.4. = Data Model Encoding . . . . . . . . . . . . . . . . . . . 33
5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 34
5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 35
6. Security = Considerations . . . . . . . . . . . . . . . . . . . 35 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. = Normative References . . . . . . . . . . . . . . . . . . 36 8.1. = Normative References . . . . . . . . . . . . . . . . . . 39
8.2. = Informative References . . . . . . . . . . . . . . . . . 38 8.2. = Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 39 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 42
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 40 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 42
B.1. = Changes to draft-ietf-lisp-lcaf-21.txt . = . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-22.txt . . . . . . . . . = 42
B.2. = Changes to draft-ietf-lisp-lcaf-20.txt . = . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-21.txt . . . . . . . . . = 43
B.3. = Changes to draft-ietf-lisp-lcaf-19.txt . = . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-20.txt . . . . . . . . . = 43
B.4. = Changes to draft-ietf-lisp-lcaf-18.txt . = . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-19.txt . . . . . . . . . = 43
B.5. = Changes to draft-ietf-lisp-lcaf-17.txt . = . . . . . . . . 41 B.5. Changes to draft-ietf-lisp-lcaf-18.txt . . . . . . . . . = 43
B.6. = Changes to draft-ietf-lisp-lcaf-16.txt . = . . . . . . . . 41 B.6. Changes to draft-ietf-lisp-lcaf-17.txt . . . . . . . . . = 43
B.7. = Changes to draft-ietf-lisp-lcaf-15.txt . = . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . = 43
B.8. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . = 44
B.9. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . = 44
B.10. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . = 44
B.11. = Changes to draft-ietf-lisp-lcaf-11.txt . = . . . . . . . . 42 B.11. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . = 44
B.12. = Changes to draft-ietf-lisp-lcaf-10.txt . = . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . = 44
B.13. = Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . = 44
B.14. = Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . = 45
B.15. = Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . = 45
B.16. = Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . = 45
B.17. = Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 43 B.17. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . = 45
B.18. = Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . = 45
B.19. = Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 43 B.19. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . = 45
B.20. = Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 43 B.20. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . = 46
B.21. = Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 43 B.21. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . = 46
B.22. = Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 44 B.22. = Changes to draft-ietf-lisp-lcaf-01.txt . . . . . = . . . . 46
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 B.23. Changes to = draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 46
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 46
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs). To = provide flexibility for current and future applications, = (RLOCs). To provide flexibility for current = and future applications,
these values = can be encoded in LISP control messages using a general = these values can be encoded in LISP control = messages using a general
syntax that = includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), = length, and
value = fields. value fields.
=
Currently = defined AFIs include IPv4 and IPv6 addresses, which are = Currently defined AFIs include IPv4 and IPv6 = addresses, which are
formatted = according to code-points assigned in [AFI] as follows: formatted according to code-points assigned in [AFI] = as follows:
=
Specific detail uses for the LCAF types defined in this = document can
be found in the use-case documents that use them. = There may be more
than one use-case document that use the same LCAF = type.
= =
IPv4 Encoded = Address: IPv4 Encoded = Address:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 1 | IPv4 Address ... | | AFI =3D 1 | IPv4 = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... = IPv4 Address | | ... = IPv4 Address |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Encoded = Address: IPv6 Encoded = Address:
=
skipping to = change at = page 4, line 25 =C2=B6 = skipping to change at page 4, line 25 =C2=B6
| = ... IPv6 Address ... | | ... IPv6 Address ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... = IPv6 Address | | ... = IPv6 Address |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
This document = describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs = the LISP protocol
uses along = with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the = LISP Canonical
Address Format = (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the = LISP-specific
encodings for = arbitrary AFI values. encodings for = arbitrary AFI values.
=
= Specific detail uses = for the LCAF types defined in this document can
= be found in the = use-case documents that use them. The same LCAF type
= may be used by more = than one use-case document. As an experimental
= specification, this = work is by definition, incomplete. The LCAF
= types defined in = this document are to support experimentation and
= intended for = cautious use in self-contained environments in support
= of the corresponding = use-case documents. This document provides
= assignment for an = initial set of approved LCAF Types (registered with
= IANA) and additional = unapproved LCAF Types [RFC6830]. The unapproved
= LCAF encodings are = defined to support further study and
= = experimentation.
= =
2. Definition of = Terms 2. Definition of Terms
=
Address Family = Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to = describe an address
encoding in = a packet. Address families are defined for IPv4 and encoding in a packet. Address families are = defined for IPv4 and
IPv6. See = [AFI] and [RFC3232] for details. The reserved AFI IPv6. See [AFI] and [RFC3232] for details. The = reserved AFI
value of 0 = is used in this specification to indicate an value of 0 is used in this specification to = indicate an
unspecified = encoded address where the length of the address is 0 unspecified encoded address where the length of = the address is 0
bytes = following the 16-bit AFI value of 0. = bytes following the 16-bit AFI value of 0.
=
Unspecified = Address Format: Unspecified Address = Format:
=
skipping to = change at = page 5, line 52 =C2=B6 = skipping to change at page 6, line 25 =C2=B6
| = . . . | | . . . = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Rsvd1/Rsvd2: = these 8-bit fields are reserved for future use and MUST = Rsvd1/Rsvd2: these 8-bit fields are = reserved for future use and MUST
be = transmitted as 0 and ignored on receipt. be transmitted as 0 and ignored on = receipt.
=
Flags: this = 8-bit field is for future definition and use. For now, = Flags: this 8-bit field is for future = definition and use. For now,
set to zero = on transmission and ignored on receipt. = set to zero on transmission and ignored on receipt.
=
Type: this = 8-bit field is specific to the LISP Canonical Address Type: this 8-bit field is specific to the LISP = Canonical Address
formatted = encodings. Currently allocated values are: formatted encodings. Currently allocated (both approved and
= = unapproved) values are:
=
Type 0: = Null Body Type Type 0: Null Body = Type
=
Type 1: AFI = List Type Type 1: AFI List = Type
=
Type 2: = Instance ID Type Type 2: = Instance ID Type
=
Type 3: AS = Number Type Type 3: AS Number = Type
=
Type 4: = Application Data Type Type 4: = Application Data Type
=
skipping to = change at = page 6, line 49 =C2=B6 = skipping to change at page 7, line 22 =C2=B6
Length: this = 16-bit field is in units of bytes and covers all of the = Length: this 16-bit field is in units of = bytes and covers all of the
LISP = Canonical Address payload, starting and including the byte = LISP Canonical Address payload, starting = and including the byte
after the = Length field. When including the AFI, an LCAF encoded after the Length field. When including the AFI, = an LCAF encoded
address = will have a minimum length of 8 bytes when the Length address will have a minimum length of 8 bytes when = the Length
field is 0. = The 8 bytes include the AFI, Flags, Type, Rsvd1, field is 0. The 8 bytes include the AFI, Flags, = Type, Rsvd1,
Rsvd2, and = Length fields. When the AFI is not next to an encoded Rsvd2, and Length fields. When the AFI is not = next to an encoded
address in = a control message, then the encoded address will have a = address in a control message, then the = encoded address will have a
minimum = length of 6 bytes when the Length field is 0. The 6 bytes = minimum length of 6 bytes when the Length = field is 0. The 6 bytes
include the = Flags, Type, Rsvd1, Rsvd2, and Length fields. include the Flags, Type, Rsvd1, Rsvd2, and Length = fields.
=
[RFC6830] = states RLOC records are sorted when encoded in control [RFC6830] states RLOC records based on an IP address are sorted when
messages so = the locator-set has consistent order across all xTRs for = encoded in control messages so the = locator-set has consistent order
a given EID. = The sort order is based on sort-key {afi, RLOC- = across all xTRs for a given EID. The sort order is based on = sort-key
address}. When an RLOC is LCAF encoded, the = sort-key is {afi, LCAF- {afi, RLOC-address}. = When an RLOC based on an IP address is = LCAF
Type}. Therefore, when a locator-set has a mix of AFI records = and encoded, the sort-key is {afi, = LCAF-Type}. Therefore, when a locator-
LCAF = records, they are ordered from smallest to largest AFI value. = set has a mix = of AFI records and LCAF records, they are ordered from
= smallest to largest AFI value.
=
4. LISP = Canonical Address Applications 4. = LISP Canonical Address Applications
=
= The following = sections define the LCAF for the currently approved
= initial set of Type = values.
= =
4.1. = Segmentation using LISP 4.1. = Segmentation using LISP
=
When multiple = organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are = using private
addresses = [RFC1918] as EID-prefixes, their address spaces must remain = addresses [RFC1918] as EID-prefixes, their = address spaces must remain
segregated due = to possible address duplication. An Instance ID in segregated due to possible address duplication. An = Instance ID in
the address = encoding can aid in making the entire AFI-based address = the address encoding can aid in making the = entire AFI-based address
= unique. unique.
=
Another use = for the Instance ID LISP Canonical Address Format is when = Another use for the Instance ID LISP = Canonical Address Format is when
creating = multiple segmented VPNs inside of a LISP site where keeping = creating multiple segmented VPNs inside of a = LISP site where keeping
=
skipping to = change at = page 12, line 5 =C2=B6 = skipping to change at page 12, line = 22 =C2=B6
The Geo = Coordinates Canonical Address Type can be used to encode = The Geo Coordinates Canonical Address Type = can be used to encode
either EID or = RLOC addresses. When used for EID encodings, you can either EID or RLOC addresses. When used for EID = encodings, you can
determine the = physical location of an EID along with the topological determine the physical location of an EID along with = the topological
location by = observing the locator-set. location = by observing the locator-set.
=
Usage: This = encoding can be used in EID or RLOC records in Map- Usage: This encoding can be used in EID or RLOC = records in Map-
Requests, = Map-Replies, Map-Registers, and Map-Notify messages. When = Requests, Map-Replies, Map-Registers, and = Map-Notify messages. When
LISP-DDT = [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, = LISP-DDT [I-D.ietf-lisp-ddt] is used as the = mapping system mechanism,
extended EIDs = are used in Map-Referral messages. = extended EIDs are used in Map-Referral messages.
=
= The use of the = Geo-Coordinates LCAF encoding raises privacy issues as
= location information = is privacy sensitive, and possibly unexpectedly
= privacy sensitive = information may be conveyed, e.g. if the location
= information = corresponds to a router located in a person's home.
= Therefore, this = encoding should not be used unless needed for
= operation of a LISP = deployment. Before electing to utilize this
= encoding, care = should be taken to ensure the appropriate policies are
= being used by the = EID for controlling the conveyed information.
= =
4.4. NAT = Traversal Scenarios 4.4. NAT = Traversal Scenarios
=
When a LISP = system is conveying global address and mapped port When a LISP system is conveying global address and = mapped port
information = when traversing through a NAT device, the NAT-Traversal = information when traversing through a NAT = device, the NAT-Traversal
LCAF Type is = used. See [I-D.ermagan-lisp-nat-traversal] for details. = LCAF Type is used. See = [I-D.ermagan-lisp-nat-traversal] for details.
=
NAT-Traversal = Canonical Address Format: = NAT-Traversal Canonical Address Format:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
=
skipping to = change at = page 14, line 5 =C2=B6 = skipping to change at page 14, line = 25 =C2=B6
determined = by parsing each field. When there are no RTRs determined by parsing each field. When there are = no RTRs
supplied, = the RTR fields can be omitted and reflected by the LCAF = supplied, the RTR fields can be omitted = and reflected by the LCAF
length = field or an AFI of 0 can be used to indicate zero RTRs length field or an AFI of 0 can be used to = indicate zero RTRs
= encoded. encoded.
=
Usage: This = encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and = Info-Reply
messages. The = mapping system does not store this information. The messages. The mapping system does not store this = information. The
information is = used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to = convey private and
public address = information when traversing NAT and firewall devices. public address information when traversing NAT and = firewall devices.
=
= Care should be taken = to protect privacy against the adverse use of a
= Global or Private = ETR RLOC Address by ensuring policy controls are
= used during EID = registrations that use this LCAF Type in RLOC-
= records. Refer to = the use case documents for additional information.
= =
4.5. Multicast = Group Membership Information 4.5. = Multicast Group Membership Information
=
Multicast = group information can be published in the mapping database. = Multicast group information can be published = in the mapping database.
So a lookup on = a group address EID can return a replication list of So a lookup on a group address EID can return a = replication list of
RLOC group = addresses or RLOC unicast addresses. The intent of this = RLOC group addresses or RLOC unicast = addresses. The intent of this
type of = unicast replication is to deliver packets to multiple ETRs at = type of unicast replication is to deliver = packets to multiple ETRs at
receiver LISP = multicast sites. The locator-set encoding for this EID = receiver LISP multicast sites. The = locator-set encoding for this EID
record type = can be a list of ETRs when they each register with "Merge = record type can be a list of ETRs when they = each register with "Merge
Semantics". = The encoding can be a typical AFI-encoded locator Semantics". The encoding can be a typical = AFI-encoded locator
address. When = an RTR list is being registered (with multiple levels address. When an RTR list is being registered (with = multiple levels
=
skipping to = change at = page 23, line 33 =C2=B6 = skipping to change at page 24, line = 33 =C2=B6
=
Length: = length in bytes starting and including the byte after this = Length: length in bytes starting and = including the byte after this
Length = field. Length field.
=
This address = format can be used to connect layer-2 domains together This address format can be used to connect layer-2 = domains together
using LISP = over an IPv4 or IPv6 core network to create a layer-2 VPN. = using LISP over an IPv4 or IPv6 core network = to create a layer-2 VPN.
In this use = case, a MAC address is being used as an EID, and the In this use case, a MAC address is being used as an = EID, and the
locator-set = that this EID maps to can be an IPv4 or IPv6 RLOCs, or locator-set that this EID maps to can be an IPv4 or = IPv6 RLOCs, or
even another = MAC address being used as an RLOC. See = even another MAC address being used as an RLOC. See
= [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate = when = [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate = when
doing EID = mobility. Refer to the Security Considerations = section for doing EID = mobility.
privacy protection. =
= Care should be taken = to protect privacy against the adverse use of a
= Layer-2 MAC Address = by ensuring policy controls are used during EID
= registrations that = use AFI=3D6 encodings in RLOC-records. Refer to the
= use case = documents for additional = information.
=
4.10.3. ASCII = Names in the Mapping Database 4.10.3. = ASCII Names in the Mapping Database
=
If DNS names = [RFC1035] or URIs [RFC3986] are stored in the LISP If DNS names [RFC1035] or URIs [RFC3986] are stored = in the LISP
Mapping = Database System, the AFI List Type can be used to carry an = Mapping Database System, the AFI List Type = can be used to carry an
ASCII = string. ASCII string.
=
ASCII LISP = Canonical Address Format: ASCII = LISP Canonical Address Format:
=
0 = 1 2 3 0 1 2 = 3
=
skipping = to change at page 27, line = 12 =C2=B6 = skipping to change at page 28, line = 12 =C2=B6
A LISP system = is required to support the AFI List LCAF Type to use A LISP system is required to support the AFI List = LCAF Type to use
this = procedure. It would skip over 10 bytes of the Geo Coordinate = this procedure. It would skip over 10 bytes = of the Geo Coordinate
LCAF Type to = get to the locator address encoding (an IPv4 locator LCAF Type to get to the locator address encoding (an = IPv4 locator
address). A = LISP system that does support the Geo Coordinate LCAF address). A LISP system that does support the Geo = Coordinate LCAF
Type can = support parsing the locator address within the Geo Type can support parsing the locator address within = the Geo
Coordinate = LCAF encoding or in the locator encoding that follows in = Coordinate LCAF encoding or in the locator = encoding that follows in
the AFI List = LCAF. the AFI List LCAF.
=
5. Experimental = LISP Canonical Address Applications 5. = Experimental LISP Canonical Address Applications
=
= The following = sections describe experimental LCAF encodings. These
= LCAF Types are not = approved (registered with IANA). The inclusion of
= these encodings in = this document are in support of further study and
= experimentation to = determine whether these encodings are functional,
= if there is a demand = for these use cases, and better understand
= deployment = considerations. As noted previously, these LCAF Types = are
= restricted to = cautious use in self-contained environments in support
= of the corresponding = use-case documents.
= =
5.1. Convey = Application Specific Data 5.1. Convey = Application Specific Data
=
When a = locator-set needs to be conveyed based on the type of When a locator-set needs to be conveyed based on the = type of
application or = the Per-Hop Behavior (PHB) of a packet, the application or the Per-Hop Behavior (PHB) of a = packet, the
Application = Data Type can be used. Application = Data Type can be used.
=
Application = Data LISP Canonical Address Format: = Application Data LISP Canonical Address Format:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
=
skipping = to change at page 35, line = 10 =C2=B6 = skipping to change at page 37, line = 10 =C2=B6
=
U: The RLOCs = listed in the AFI-encoded addresses in the next longword = U: The RLOCs listed in the AFI-encoded = addresses in the next longword
can accept = GUE encapsulation using destination UDP port TBD can accept GUE encapsulation using destination UDP = port TBD
= [I-D.herbert-gue]. = [I-D.herbert-gue].
=
Usage: This = encoding can be used in RLOC records in Map-Requests, Usage: This encoding can be used in RLOC records in = Map-Requests,
Map-Replies, = Map-Registers, and Map-Notify messages. = Map-Replies, Map-Registers, and Map-Notify messages.
=
6. Security = Considerations 6. Security = Considerations
=
There are no security considerations for this = specification. The This document is classified as Experimental. = The LCAF encodings
security considerations are documented for the protocols that use defined in this = document are intended to be used with = their
LISP Canonical Addressing. corresponding use cases and = in self-contained environments. Users
= should carefully = consider how the [I-D.ietf-lisp-sec] = threat model
= applies to their = particular use case.
=
The use of the = Geo-Coordinates LCAF Type may raise physical privacy The use of the Geo-Coordinates LCAF Type may raise = physical privacy
issues. Care = should be taken when configuring the mapping system to issues. Care should be taken when configuring the = mapping system to
use specific = policy parameters so geo-location information is not use specific policy parameters so geo-location = information is not
returned = gratuitously. It is recommended that any documents that = returned gratuitously. It is recommended = that any documents that
specify the = use of the Geo-Coordinates LCAF Type should consider the = specify the use of the Geo-Coordinates LCAF = Type should consider the
applicability = of the BCP160 [RFC6280] for location-based privacy applicability of the BCP160 [RFC6280] for = location-based privacy
= protection. protection.
=
= Additional privacy = concerns have arisen since publication of BCP160,
= and future work on = LISP should examine potential threats beyond
= BCP160 and address = improving privacy and security for LISP
= = deployments.
= =
7. IANA = Considerations 7. IANA = Considerations
=
This document = defines a canonical address format encoding used in This document defines a canonical address format = encoding used in
LISP control = messages and in the encoding of lookup keys for the LISP = LISP control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Such address format is based on a fixed AFI = Mapping Database System. Such address = format is based on a fixed AFI
(16387) and a = LISP LCAF Type field. (16387) and a = LISP LCAF Type field.
=
The LISP LCAF = Type field is an 8-bit field specific to the LISP The LISP LCAF Type field is an 8-bit field specific = to the LISP
Canonical = Address formatted encodings, for which IANA is to create = Canonical Address formatted encodings, for = which IANA is to create
and maintain a = new registry (as outlined in [RFC5226]) entitled "LISP and maintain a new registry (as outlined in = [RFC5226]) entitled "LISP
LCAF Type". = Initial values for the LISP LCAF Type registry are given = LCAF Type". Initial values for the LISP = LCAF Type registry are given
below. = Future assignments are to be made through expert = review with below. Future = assignments are to be made based on = specification
a specification required= publication. Assignments consist of a LISP required. Assignments = consist of a LISP LCAF Type name and its
LCAF Type = name and its associated value: = associated value:
=
= +-------+------------------------------+------------+ = +-------+------------------------------+------------+
| = Value | LISP LCAF Type Name | Definition | | Value | LISP LCAF Type Name | = Definition |
= +-------+------------------------------+------------+ = +-------+------------------------------+------------+
| 0 = | Null Body Type | Section 3 | | 0 | Null Body Type | = Section 3 |
| 1 = | AFI List Type | Section 3 | | 1 | AFI List Type | = Section 3 |
| 2 = | Instance ID Type | Section 3 | | 2 | Instance ID Type | = Section 3 |
| 3 = | AS Number Type | Section 3 | | 3 | AS Number Type | = Section 3 |
| 5 = | Geo Coordinates Type | Section 3 | | 5 | Geo Coordinates Type | = Section 3 |
| 7 = | NAT-Traversal Type | Section 3 | | 7 | NAT-Traversal Type | = Section 3 |
=
skipping = to change at page 39, line = 15 =C2=B6 = skipping to change at page 41, line = 20 =C2=B6
= [I-D.ietf-lisp-crypto] = [I-D.ietf-lisp-crypto]
= Farinacci, D. and B. Weis, "LISP Data-Plane Farinacci, D. and B. Weis, "LISP = Data-Plane
= Confidentiality", draft-ietf-lisp-crypto-10 (work in Confidentiality", = draft-ietf-lisp-crypto-10 (work in
= progress), October 2016. = progress), October 2016.
=
= [I-D.ietf-lisp-ddt] = [I-D.ietf-lisp-ddt]
= Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- = Smirnov, "LISP Delegated Database = Tree", draft-ietf-lisp-
= ddt-08 (work in progress), September 2016. ddt-08 (work in progress), September = 2016.
=
= [I-D.ietf-lisp-sec]
= Maino, = F., Ermagan, V., Cabellos-Aparicio, A., and D.
= Saucez, = "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
= (work in = progress), November 2016.
= =
= [I-D.portoles-lisp-eid-mobility] = [I-D.portoles-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", = draft-portoles-lisp-eid-
= mobility-01 (work in progress), October 2016. mobility-01 (work in progress), October = 2016.
=
= [I-D.quinn-vxlan-gpe] = [I-D.quinn-vxlan-gpe]
= Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., = Quinn, P., Manur, R., Kreeger, = L., Lewis, D., Maino, F.,
= Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, = Smith, M., Agarwal, P., Yong, L., = Xu, X., Elzur, U., Garg,
P., = and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol = Extension for VXLAN",
=
skipping = to change at page 40, line = 19 =C2=B6 = skipping to change at page 42, line = 32 =C2=B6
The authors = would like to thank Albert Cabellos-Aparicio and Florin = The authors would like to thank Albert = Cabellos-Aparicio and Florin
Coras for = discussions that lead to the definition of the Replication = Coras for discussions that lead to the = definition of the Replication
List Entry = LCAF type. List Entry LCAF = type.
=
Thanks goes to = Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto = Rodriguez-Natal for
suggesting new = LCAF types. suggesting new LCAF = types.
=
Thanks also = goes to Terry Manderson for assistance obtaining a LISP = Thanks also goes to Terry Manderson for = assistance obtaining a LISP
AFI value from = IANA. AFI value from IANA.
=
= And finally, the = authors thank Stephen Farrell (Security Area
= Director) and = Deborah Brungard (Routing Area Director) for their
= suggested text to = get the document through IESG review.
= =
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-lcaf-21.txt B.1. = Changes to draft-ietf-lisp-lcaf-22.txt
=
= o Submitted = November 2016.
=
= o Take into account = RTG area director Deborah Brungard's comments
= = suggestions.
=
= o The changes put = in shoudl clear Stephen's DISCUSS comments on
= RLOC-record = ordering and privacy concerns with the Geo-Coordinate
= LCAF = type.
=
= B.2. Changes to = draft-ietf-lisp-lcaf-21.txt
=
o Submitted = November 2016. o Submitted = November 2016.
=
o Reflect = Alexey's DISCUSS comments. o = Reflect Alexey's DISCUSS comments.
=
o Add text to = intro section that says the details for any LCAF type o Add text to intro section that says the details = for any LCAF type
can be = found in other use-case documents. = can be found in other use-case documents.
=
o Provide = general examples for JSON and DNS LCAF types. o Provide general examples for JSON and DNS LCAF = types.
=
B.2. Changes to = draft-ietf-lisp-lcaf-20.txt B.3. Changes to = draft-ietf-lisp-lcaf-20.txt
=
o Submitted = October 2016. o Submitted October = 2016.
=
o Put in = references to DNS names and URIs per Alexey's comment. o Put in references to DNS names and URIs per = Alexey's comment.
=
B.3. Changes to = draft-ietf-lisp-lcaf-19.txt B.4. Changes to = draft-ietf-lisp-lcaf-19.txt
=
o Submitted = October 2016. o Submitted October = 2016.
=
o Make it = more clear that any use-case documents that use the Geo- = o Make it more clear that any use-case = documents that use the Geo-
Coordinates = LCAF type should discuss RFC6280 compliance. Coordinates LCAF type should discuss RFC6280 = compliance.
=
B.4. Changes to = draft-ietf-lisp-lcaf-18.txt B.5. Changes to = draft-ietf-lisp-lcaf-18.txt
=
o Submitted = October 2016 after October 13th telechat. o Submitted October 2016 after October 13th = telechat.
=
o Addressed = comments from Ben Campbell, Jari Arrko, Stephen Farrel, = o Addressed comments from Ben Campbell, = Jari Arrko, Stephen Farrel,
Peter Yee, = Dale Worley, Mirja Kuehlewind, and Suresh Krishnan. Peter Yee, Dale Worley, Mirja Kuehlewind, and = Suresh Krishnan.
=
B.5. Changes to = draft-ietf-lisp-lcaf-17.txt B.6. Changes to = draft-ietf-lisp-lcaf-17.txt
=
o Submitted = October 2016. o Submitted October = 2016.
=
o Addressed = comments from Gen-ART reviewer Peter Yee. o Addressed comments from Gen-ART reviewer Peter = Yee.
=
o Addressed = IESG last-call comments from Suresh Krishnan. o Addressed IESG last-call comments from Suresh = Krishnan.
=
B.6. Changes to = draft-ietf-lisp-lcaf-16.txt B.7. Changes to = draft-ietf-lisp-lcaf-16.txt
=
o Submitted = October 2016. o Submitted October = 2016.
=
o Addressed = comments from Security Directorate reviewer David o Addressed comments from Security Directorate = reviewer David
= Mandelberg. Mandelberg.
=
B.7. Changes to = draft-ietf-lisp-lcaf-15.txt B.8. Changes to = draft-ietf-lisp-lcaf-15.txt
=
o Submitted = September 2016. o Submitted = September 2016.
=
o Addressed = comments from Routing Directorate reviewer Stig Venass. = o Addressed comments from Routing = Directorate reviewer Stig Venass.
=
B.8. Changes to = draft-ietf-lisp-lcaf-14.txt B.9. Changes to = draft-ietf-lisp-lcaf-14.txt
=
o Submitted = July 2016. o Submitted July = 2016.
=
o Fix IDnits = errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, = document
= shepherd. shepherd.
=
B.9. Changes to = draft-ietf-lisp-lcaf-13.txt B.10. Changes to = draft-ietf-lisp-lcaf-13.txt
=
o Submitted = May 2016. o Submitted May = 2016.
=
o Explain the = Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in = length and the
Instance-ID = field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header = is 24-bits.
=
B.10. Changes to = draft-ietf-lisp-lcaf-12.txt B.11. Changes to = draft-ietf-lisp-lcaf-12.txt
=
o Submitted = March 2016. o Submitted March = 2016.
=
o Updated = references and document timer. o = Updated references and document timer.
=
o Removed the = R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast = Info Type LCAF
since = working group decided to not go forward with draft- since working group decided to not go forward with = draft-
= farinacci-lisp-mr-signaling-03.txt in favor of draft- = ietf-lisp- = farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
= signal-free-00.txt. = signal-free-00.txt.
=
B.11. Changes to = draft-ietf-lisp-lcaf-11.txt B.12. Changes to = draft-ietf-lisp-lcaf-11.txt
=
o Submitted = September 2015. o Submitted = September 2015.
=
o Reflecting = comments from Prague LISP working group. o Reflecting comments from Prague LISP working = group.
=
o Readying = document for a LISP LCAF registry, RFC publication, and = o Readying document for a LISP LCAF = registry, RFC publication, and
for new use = cases that will be defined in the new charter. for new use cases that will be defined in the new = charter.
=
B.12. Changes to = draft-ietf-lisp-lcaf-10.txt B.13. Changes to = draft-ietf-lisp-lcaf-10.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix = coauthor Job's contact information. = o Fix coauthor Job's contact information.
=
B.13. Changes to = draft-ietf-lisp-lcaf-09.txt B.14. Changes to = draft-ietf-lisp-lcaf-09.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix IANA = Considerations section to request a registry to allocate = o Fix IANA Considerations section to = request a registry to allocate
and track = LCAF Type values. and track LCAF = Type values.
=
B.14. Changes to = draft-ietf-lisp-lcaf-08.txt B.15. Changes to = draft-ietf-lisp-lcaf-08.txt
=
o Submitted = April 2015. o Submitted April = 2015.
=
o Comment = from Florin. The Application Data Type length field has a = o Comment from Florin. The Application = Data Type length field has a
typo. The = field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and = not "8 + n".
=
o Fix length = fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using = Recursive LISP
Canonical = Address Encodings", "Generic Database Mapping Lookups", = Canonical Address Encodings", "Generic = Database Mapping Lookups",
and "Data = Model Encoding". and "Data Model = Encoding".
=
B.15. Changes to = draft-ietf-lisp-lcaf-07.txt B.16. Changes to = draft-ietf-lisp-lcaf-07.txt
=
o Submitted = December 2014. o Submitted = December 2014.
=
o Add a new = LCAF Type called "Encapsulation Format" so decapsulating = o Add a new LCAF Type called "Encapsulation = Format" so decapsulating
xTRs can = inform encapsulating xTRs what data-plane encapsulations = xTRs can inform encapsulating xTRs what = data-plane encapsulations
they = support. they support.
=
B.16. Changes to = draft-ietf-lisp-lcaf-06.txt B.17. Changes to = draft-ietf-lisp-lcaf-06.txt
=
o Submitted = October 2014. o Submitted October = 2014.
=
o Make it = clear how sorted RLOC records are done when LCAFs are used = o Make it clear how sorted RLOC records are = done when LCAFs are used
as the RLOC = record. as the RLOC = record.
=
B.17. Changes to = draft-ietf-lisp-lcaf-05.txt B.18. Changes to = draft-ietf-lisp-lcaf-05.txt
=
o Submitted = May 2014. o Submitted May = 2014.
=
o Add a = length field of the JSON payload that can be used for either = o Add a length field of the JSON payload = that can be used for either
binary or = text encoding of JSON data. = binary or text encoding of JSON data.
=
B.18. Changes to = draft-ietf-lisp-lcaf-04.txt B.19. Changes to = draft-ietf-lisp-lcaf-04.txt
=
o Submitted = January 2014. o Submitted January = 2014.
=
o Agreement = among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI = 16-bit field
adjacent to = the address. This will make the encoding consistent adjacent to the address. This will make the = encoding consistent
with all = other LCAF type address encodings. = with all other LCAF type address encodings.
=
B.19. Changes to = draft-ietf-lisp-lcaf-03.txt B.20. Changes to = draft-ietf-lisp-lcaf-03.txt
=
o Submitted = September 2013. o Submitted = September 2013.
=
o Updated = references and author's affilations. = o Updated references and author's affilations.
=
o Added = Instance-ID to the Multicast Info Type so there is relative = o Added Instance-ID to the Multicast Info = Type so there is relative
ease in = parsing (S,G) entries within a VPN. = ease in parsing (S,G) entries within a VPN.
=
o Add port = range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data = LCAF Type.
=
o Add a new = JSON LCAF Type. o Add a new JSON = LCAF Type.
=
o Add Address = Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow = attributes to be attached
to an = address. to an address.
=
B.20. Changes to = draft-ietf-lisp-lcaf-02.txt B.21. Changes to = draft-ietf-lisp-lcaf-02.txt
=
o Submitted = March 2013. o Submitted March = 2013.
=
o Added new = LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to = support LISP
replication = engineering use cases. = replication engineering use cases.
=
o Changed = references to new LISP RFCs. o = Changed references to new LISP RFCs.
=
B.21. Changes to = draft-ietf-lisp-lcaf-01.txt B.22. Changes to = draft-ietf-lisp-lcaf-01.txt
=
o Submitted = January 2013. o Submitted January = 2013.
=
o Change = longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in = section 4.4.
=
o Added = reference to WGS-84 in section 4.4. = o Added reference to WGS-84 in section 4.4.
=
B.22. Changes to = draft-ietf-lisp-lcaf-00.txt B.23. Changes to = draft-ietf-lisp-lcaf-00.txt
=
o Posted = first working group draft August 2012. = o Posted first working group draft August 2012.
=
o This draft = was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from = draft-farinacci-lisp-lcaf-10.txt.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
=
skipping = to change at page 44, line = 31 =C2=B6 = skipping to change at page 47, line = 15 =C2=B6
= Brocade Brocade
San Jose, = CA San Jose, CA
USA = USA
=
Email: = dmm@1-4-5.net Email: = dmm@1-4-5.net
=
Job = Snijders Job Snijders
NTT = Communications NTT = Communications
Theodorus = Majofskistraat 100 Theodorus = Majofskistraat 100
Amsterdam = 1065 SZ Amsterdam 1065 SZ
NL The Netherlands
=
Email: = job@ntt.net Email: = job@ntt.net
 End of changes. 44 change blocks. 
101 lines changed or = deleted 169 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_898C72A4-2300-48DF-960B-28E8BB6522FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 22, 2016, at 10:17 AM, Dino Farinacci = wrote: >=20 >> We're talking past one another. Each time you re-assure me >> that there's nothing to worry about but don't say how to >> deal with the case about which I'm asking. Maybe if someone >> else were to try respond that'd get us out of that loop? :-) >=20 > The chairs are going to respond so we can get out of this loop. >=20 >> Had you pointed at that draft before? If so, I guess I >> missed it (and sorry about that). However, BCP160 is >> *still* not a useful reference there or here, and I was >> not suggesting referring to that draft (of whose existence >> I wasn't aware;-). If your argument is that the privacy >> considerations related to this section of the lcaf draft >> are dealt with in that lisp-geo draft, then yes I would >> argue that it needs to be referred to, but I think it'd >> be better to call out here that location information is >> privacy sensitive and ought not be used unless it's needed. >> (And that latter is not stated in the lisp-geo draft.) >=20 > I can certainly refer to it as well as the NAT-traversal draft. But = want the chairs to give me their approval. >=20 >> Does it support long-term symmetric keys stored in the >> format defined here? If so, then more text on that is >> needed somewhere. If the lcaf format is only for public >> keys, then it's ok already. >=20 > There is no long-term key storage. The format is used only in message = exchange. >=20 >> We don't need a mediator. If the WG chairs or AD say that the >> WG want all this text, then I'll move to an abstain once we've >> sorted the other discuss points. >=20 > Okay, sounds good. >=20 > Dino >=20 --Apple-Mail=_898C72A4-2300-48DF-960B-28E8BB6522FF-- From nobody Mon Nov 28 22:24:20 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A854127735; Mon, 28 Nov 2016 22:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLV7UUQc_J3t; Mon, 28 Nov 2016 22:23:37 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B59129563; Mon, 28 Nov 2016 22:23:36 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id E3E7440671; Tue, 29 Nov 2016 07:23:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 7F7841A006E; Tue, 29 Nov 2016 07:23:34 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0319.002; Tue, 29 Nov 2016 07:23:33 +0100 From: To: Geoff Huston Thread-Topic: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt Thread-Index: AQHSSajh01bAeatvw0+OeG+VNv4OX6DvfISg Date: Tue, 29 Nov 2016 06:23:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DB9827@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <745BD36A-8AEF-4917-AB88-F1010B54E213@apnic.net> <787AE7BB302AE849A7480A190F8B933009DB9254@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <46143E39-F8EF-4E41-8893-C166FF5F8C5E@apnic.net> In-Reply-To: <46143E39-F8EF-4E41-8893-C166FF5F8C5E@apnic.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , "draft-ietf-lisp-type-iana.all@ietf.org" , Jon Hudson Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-type-iana-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 06:23:40 -0000 SGkgR2VvZmYsDQoNCkFjdHVhbGx5LCB0aGUgcHJvcG9zZWQgc3RhdHVzIG9mIHRoaXMgZG9jdW1l bnQgd2FzIG5vdCB0cmlnZ2VyZWQgYnkgdGhlIGFjdGlvbiB0byBjcmVhdGUgdGhlIElBTkEgcmVn aXN0ZXIgKHRoYXQgY2FuIGJlIGRvbmUgdmlhIGFuIEluZm9ybWF0aW9uYWwgRG9jdW1lbnQpIGJ1 dCB3aXRoIHRoZSBhY3Rpb24gdG8gc3BlY2lmeSBhIHNoYXJlZCBMSVNQIGV4dGVuc2lvbiBtZXNz YWdlIGZvcm1hdCBhbmQgYXNzaWduIGEgY29kZXBvaW50ICgxNSkgZm9yIHRoYXQgcHVycG9zZS4g DQoNCkZXSVcsIHRoaXMgcG9pbnQgd2FzIG1lbnRpb25lZCBpbiB0aGUgd3JpdGUtdXA6DQoNCj09 DQogICAgICBUaGlzIGRvY3VtZW50IHRhcmdldHMgdG8gZm9sbG93IHN0YW5kYXJkIHRyYWNrLCBo ZW5jZSBhaW1pbmcgYXQgdGhlDQogICAgICBpbml0aWFsIGxldmVsIG9mICJQcm9wb3NlZCBTdGFu ZGFyZCIuDQogICAgICBJIHBlcnNvbmFsbHkgYXJndWVkIHdpdGggdGhlIGF1dGhvcnMgdGhhdCB1 c3VhbGx5IGRvY3VtZW50cw0KICAgICAgYWltaW5nIGF0IGNyZWF0aW5nIElBTkEgcmVnaXN0cmll cyBhcmUgImluZm9ybWF0aW9uYWwiLg0KICAgICAgWWV0LCBhcyB0aGUgYXV0aG9ycyByaWdodGZ1 bGx5IHBvaW50ZWQgb3V0LCB0aGUgZG9jdW1lbnQgYWxzbw0KICAgICAgcHJvcG9zZXMgdGhlIGV4 cGVyaW1lbnRhbCBwYWNrZXQgZm9ybWF0LCBmb3Igd2hpY2ggc3RhbmRhcmQNCiAgICAgIHRyYWNr IGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUuDQogICAgICBBcyBhIHNoZXBoZXJkIG9mIHRoZSBkb2N1 bWVudCBJIGFtIGZpbmUga2VlcGluZyB0aGlzDQogICAgICBpbnRlbmRlZCBzdGF0dXMuIFRvIGJl IG5vdGVkIHRoYXQgdGhlIGRvY3VtZW50IHBhc3NlZCB0aGUNCiAgICAgIFdHTEMgd2l0aCB0aGUg c3VjaCBpbnRlbmRlZCBzdGF0dXMuIE5vIGNvbmNlcm4gd2FzIHJhaXNlZCBieSB0aGUNCiAgICAg IFdHIG1lbWJlcnMuIEFzIGZvciB0aGUgSUVURiBwcm9jZXNzLCBpdCBpcyB1cCB0byB0aGUNCiAg ICAgIElFU0cgdG8gYXNzaWduIHRoZSBtb3N0IGFwcHJvcHJpYXRlIHN0YXR1cyB0byB0aGlzIGRv Y3VtZW50Lg0KPT0NCg0KVGhhdCdzIHNhaWQsIEknbSBPSyB0byBjaGFuZ2UgdGhlIHN0YXR1cyB0 byBFWFAgaWYgdGhhdCBpcyBtb3JlIGFwcHJvcHJpYXRlLg0KDQpUaGFuayB5b3UuDQoNCkNoZWVy cywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBHZW9mZiBI dXN0b24gW21haWx0bzpnaWhAYXBuaWMubmV0XQ0KPiBFbnZvecOpwqA6IGx1bmRpIDI4IG5vdmVt YnJlIDIwMTYgMTk6NTQNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiBDY8Kg OiBaaGFuZ3hpYW4gKFhpYW4pOyBydGctYWRzQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOyBs aXNwQGlldGYub3JnOw0KPiBqb25hdGhhbi5oYXJkd2lja0BtZXRhc3dpdGNoLmNvbTsgZHJhZnQt aWV0Zi1saXNwLXR5cGUtaWFuYS5hbGxAaWV0Zi5vcmc7DQo+IEpvbiBIdWRzb24NCj4gT2JqZXTC oDogUmU6IFtsaXNwXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLWxpc3AtdHlwZS1pYW5hLTAz LnR4dA0KPiANCj4gWW91IGFwcGVhciB0byBoYXZlIG1pc3VuZGVyc3Rvb2QgbWUgLSBpdHMgX25v dF8gdGhhdCB0aGlzIGRyYWZ0IHNlZWtzIHRvDQo+IGNyZWF0ZSBhbg0KPiBJQU5BIHJlZ2lzdHJ5 IGZvciBhbiBleHBlcmltZW50YWwgc3BlY2lmaWNhdGlvbiB0aGF0IEkgZm91bmQgdG8gYmUNCj4g YW5vbWFsb3VzLiBXaGF0DQo+IEkgZm91bmQgYW5vbWFsb3VzIHdhcyB0aGF0IHRoZSBkb2N1bWVu dCBwcm9wb3Npbmcgc3VjaCBhbiBhY3Rpb24gd2FzDQo+IGl0c2VsZiBwcm9wb3NlZA0KPiB0byBi ZSBhIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudC4NCj4gDQo+IENsZWFyIG5vdz8NCj4gDQo+IHRo YW5rcywNCj4gDQo+ICAgR2VvZmYNCj4gDQo+IA0KPiANCj4gPiBPbiAyOSBOb3YuIDIwMTYsIGF0 IDEyOjQzIGFtLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NCj4gPG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgR29lZmYsDQo+ID4NCj4gPiBJ IGhhdmUgb25lIGNvbW1lbnQgYWJvdXQgdGhpcyBwYXJ0IG9mIHlvdXIgcmV2aWV3Og0KPiA+DQo+ ID4+IEl0IHNlZW1zIGFub21hbG91cyB0byBtZSB0aGF0IGEgcmVxdWVzdCB0byBzZXQgdXAgYW4g SUFOQSBSZWdpc3RyeSBmb3INCj4gYW4NCj4gPj4gRXhwZXJpbWVudGFsIFByb3RvY29sIChSRkM2 ODMwIGlzIEV4cGVyaW1lbnRhbCkgaXMgaXRzZWxmIHByb3Bvc2VkIHRvDQo+IGJlIGENCj4gPj4g U3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50Lg0KPiA+DQo+ID4gRldJVywgSSdtIGF3YXJlIG9mIGFu IElBTkEgcmVnaXN0cnkgZm9yIGFuIGV4cGVyaW1lbnRhbCBwcm90b2NvbCB0aGF0DQo+IHlvdSBj YW4gY2hlY2sgaGVyZToNCj4gPiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3RjcC1w YXJhbWV0ZXJzL3RjcC0NCj4gcGFyYW1ldGVycy54aHRtbCNtcHRjcC1vcHRpb24tc3VidHlwZXMN Cj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPj4gRGUgOiBsaXNwIFttYWlsdG86bGlzcC1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIEdlb2ZmIEh1c3Rvbg0KPiA+PiBFbnZvecOpIDogbHVuZGkgMjggbm92ZW1i cmUgMjAxNiAwNDowNA0KPiA+PiDDgCA6IFpoYW5neGlhbiAoWGlhbik7IHJ0Zy1hZHNAaWV0Zi5v cmcNCj4gPj4gQ2MgOiBydGctZGlyQGlldGYub3JnOyBsaXNwQGlldGYub3JnOyBqb25hdGhhbi5o YXJkd2lja0BtZXRhc3dpdGNoLmNvbTsNCj4gPj4gZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS5h bGxAaWV0Zi5vcmc7IEpvbiBIdWRzb24NCj4gPj4gT2JqZXQgOiBbbGlzcF0gUnRnRGlyIHJldmll dzogZHJhZnQtaWV0Zi1saXNwLXR5cGUtaWFuYS0wMy50eHQNCj4gPj4NCj4gPj4gSGVsbG8sDQo+ ID4+DQo+ID4+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzDQo+IGRyYWZ0Lg0KPiA+Pg0KPiA+PiBUaGUgUm91dGluZyBEaXJl Y3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+ ID4+IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyBy ZXZpZXcsIGFuZA0KPiBzb21ldGltZXMNCj4gPj4gb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVy cG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZQ0KPiB0bw0KPiA+PiB0 aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlLA0KPiA+PiBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gPj4NCj4gPj4gQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsDQo+IGl0 DQo+ID4+IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcg d2l0aCBhbnkgb3RoZXIgSUVURg0KPiBMYXN0DQo+ID4+IENhbGwgY29tbWVudHMgdGhhdCB5b3Ug cmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaA0KPiA+PiBkaXNjdXNz aW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gPj4NCj4gPj4gRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtbGlzcC10eXBlLWlhbmEtMDMudHh0DQo+ID4+IFJldmlld2VyOiBHZW9mZiBIdXN0b24g UmV2aWV3DQo+ID4+IERhdGU6IDI4IE5vdmVtYmVyIDIwMTYNCj4gPj4gSUVURiBMQyBFbmQgRGF0 ZTogbm90IGNhbGxlZA0KPiA+PiBJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KPiA+ Pg0KPiA+PiBTdW1tYXJ5Og0KPiA+Pg0KPiA+PiBJIGhhdmUgc2lnbmlmaWNhbnQgY29uY2VybnMg YWJvdXQgdGhpcyBkb2N1bWVudCBhbmQgcmVjb21tZW5kIHRoYXQgdGhlDQo+ID4+IFJvdXRpbmcg QURzIGRpc2N1c3MgdGhlc2UgaXNzdWVzIGZ1cnRoZXIgd2l0aCB0aGUgYXV0aG9ycyBhbmQgdGhl IElBTkEuDQo+ID4+DQo+ID4+IENvbW1lbnRzOg0KPiA+Pg0KPiA+PiBEcmFmdCBxdWFsaXR5IGFu ZCByZWFkYWJpbGl0eS4NCj4gPj4NCj4gPj4gVGhlIHRoaXJkIHBhcmFncmFwaCBvZiB0aGUgSW50 cm9kdWN0aW9uIGlzIHVuY2xlYXIuIEdpdmVuIHRoYXQgTElTUA0KPiBpdHNlbGYNCj4gPj4gaXMg YW4gZXhwZXJpbWVudGFsIHNwZWNpZmljYXRpb24gaXQgaXMgaGFyZCB0byB1bmRlcnN0YW5kIHRo ZQ0KPiBkaXN0aW5jdGlvbg0KPiA+PiBiZWluZyBtYWRlIGJldHdlZW4gdGhlICJleHBlcmltZW50 YXRpb24gcHVycG9zZXMiIGFuZCBzb21lIG90aGVyDQo+ID4+IHVuZGVzY3JpYmVkIHB1cnBvc2Ug d2hpY2ggdGhpcyByZXZpZXdlciBjYW4gb25seSBjb25jbHVkZSBpcyBhbHNvIGFuDQo+ID4+IGV4 cGVyaW1lbnRhdGlvbiBwdXJwb3NlLiBJIHN1Z2dlc3QgcmUtdGhpbmtpbmcgdGhlIGludGVudCBv ZiB0aGlzDQo+ID4+IHBhcmFncmFwaCBhbmQgZXhwcmVzc2luZyBpdCBpbiBzaW1wbGVyIHRlcm1z Lg0KPiA+Pg0KPiA+PiBJbiBzZWN0aW9uIDIsIHRoZSB1c2Ugb2YgdGhlIG5vcm1hdGl2ZSAiTVVT VCIgc2VlbXMgdG8gYmUNCj4gaW5hcHByb3ByaWF0ZSwNCj4gPj4gcGFydGljdWxhcmx5IHdoZW4g YSBub24tbm9ybWF0aXZlICJtdXN0IiBpdXMgdXNlZCBpbiBzZWN0aW9uIDQgaW4gYW4NCj4gPj4g aWRlbnRpY2FsIGNvbnRleHQuDQo+ID4+DQo+ID4+IE1ham9yIElzc3VlczoNCj4gPj4NCj4gPj4g SXQgc2VlbXMgYW5vbWFsb3VzIHRvIG1lIHRoYXQgYSByZXF1ZXN0IHRvIHNldCB1cCBhbiBJQU5B IFJlZ2lzdHJ5IGZvcg0KPiBhbg0KPiA+PiBFeHBlcmltZW50YWwgUHJvdG9jb2wgKFJGQzY4MzAg aXMgRXhwZXJpbWVudGFsKSBpcyBpdHNlbGYgcHJvcG9zZWQgdG8NCj4gYmUgYQ0KPiA+PiBTdGFu ZGFyZHMgVHJhY2sgZG9jdW1lbnQuDQo+ID4+DQo+ID4+IEZ1cnRoZXJtb3JlLCB0aGUgZG9jdW1l bnQgc3RhdGVzIHRoYXQgYWRkaXRpb25hbCB2YWx1ZXMgYmUgYXNzaWduZWQgdmlhDQo+IGENCj4g Pj4gU3RhbmRhcmRzIEFjdGlvbi4gQWdhaW4sIGl0IGFwcGVhcnMgYW5vbWFsb3VzIHRvIG1lIHRo YXQgYQ0KPiBzcGVjaWZpY2F0aW9uDQo+ID4+IG9mIGEgcGFyYW1ldGVyIHZhbHVlIG9mIGFuIGV4 cGVyaW1lbnRhbCBwcm90b2NvbCBiZSBkZXNjcmliZWQgYnkgYQ0KPiA+PiBTdGFuZGFyZHMgVHJh Y2sgYWN0aW9uLg0KPiA+Pg0KPiA+PiBJZiBSRkM2ODMwIGlzIHJldmlzZWQgYW5kIGlzIHJlLXB1 Ymxpc2hlZCBhcyBhIFN0YW5kYXJkcyBUcmFjaw0KPiA+PiBzcGVjaWZpY2F0aW9uIHRoZW4gdGhl c2UgcG9pbnRzIGFyZSBvZiBjb3Vyc2Ugbm90IHJlbGV2YW50LCBidXQgdW50aWwNCj4gc3VjaA0K PiA+PiBhIHB1YmxpY2F0aW9uIHRha2VzIHBsYWNlLCBzcGVjaWZ5aW5nIGFuIElBTkEgcGFyYW1l dGVyIHJlZ2lzdHJ5IGFzIGENCj4gPj4gU3RhbmRhcmRzIFRyYWNrIGFjdGlvbiBmb3IgYW4gZXhw ZXJpbWVudGFsIHByb3RvY29sIHNlZW1zIHRvIG1lIHRvIGJlDQo+ID4+IGFub21hbG91cyBhbmQg c2hvdWxkIG5vdCBwcm9jZWVkIHVubGVzcyB0aGUgSUVTRyBzcGVjaWZpY2FsbHkgYWdyZWVzDQo+ IHdpdGgNCj4gPj4gdGhpcyBhcHByb2FjaC4gQWx0ZXJuYXRpdmVseSBSRkM1MjI2IGNvdWxkIGJl IGZ1cnRoZXIgcmV2aXNlZCB0bw0KPiA+PiBleHBsaWNpdGx5IGRlc2NyaWJlIHRoZSBndWlkZWxp bmVzIGFzIHRoZXkgcmVsYXRlIHRvIEV4cGVyaW1lbnRhbA0KPiA+PiBTcGVjaWZpY2F0aW9ucyAo YXMgZGlzdGluY3QgZnJvbSBleHBlcmltZW50YWwgYWxsb2NhdGlvbnMgd2l0aGluDQo+IFN0YW5k YXJkcw0KPiA+PiBUcmFjayBzcGVjaWZpY2F0aW9ucyksIGFzIHRoaXMgYXJlYSBhcHBlYXJzIHRv IGJlIHVuY2xlYXIgZnJvbSBteQ0KPiByZWFkaW5nDQo+ID4+IG9mIFJGQzUyMjYuDQo+ID4+DQo+ ID4+IEhvd2V2ZXIgaXQgaXMgbm90IGZvciBtZSB0byByZXNvbHZlIHRoaXMgaXNzdWUsIG5vciBp cyBpdCB1cCB0byB0aGUNCj4gZHJhZnQNCj4gPj4gYXV0aG9ycywgb3IgdGhlIExJU1Agd29ya2lu ZyBncm91cCwgYXMgZmFyIGFzIEkgY2FuIHRlbGwuICBJdCBpcyB1cCB0bw0KPiB0aGUNCj4gPj4g SUVTRyBhbmQNCj4gPj4gSUFOQSB0byBjbGFyaWZ5IHRoaXMgc2l0dWF0aW9uIGFuZCBhbGxvdyBJ QU5BIHRvIGJlIGdpdmVuIGNsZWFyDQo+IGRpcmVjdGlvbnMNCj4gPj4gYXMgdG8gaG93IHRvIG1h aW50YWluIHBhcmFtZXRlciByZWdpc3RyaWVzIGZvciBleHBlcmltZW50YWwNCj4gc3BlY2lmaWNh dGlvbnMNCj4gPj4gd2hpbGUgdGhleSByZW1haW4gZXhwZXJpbWVudHMuDQo+ID4+DQo+ID4+DQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IGxpc3AgbWFpbGluZyBsaXN0DQo+ID4+IGxpc3BAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9saXNwDQoNCg== From nobody Wed Nov 30 03:43:23 2016 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A83129FFA; Wed, 30 Nov 2016 03:43:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 03:43:18 -0800 Archived-At: Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 11:43:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol of the IETF. Title : LISP Shared Extension Message & IANA Registry for LISP Packet Type Allocations Authors : Mohamed Boucadair Christian Jacquenet Filename : draft-ietf-lisp-type-iana-04.txt Pages : 5 Date : 2016-11-30 Abstract: This document defines a registry for LISP Packet Type allocations. It also specifies a LISP shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lisp-type-iana-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-type-iana-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 30 03:54:46 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0D51296AE; Wed, 30 Nov 2016 03:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-tW9t-VIclA; Wed, 30 Nov 2016 03:54:38 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34223129B19; Wed, 30 Nov 2016 03:53:33 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id B30E0C0242; Wed, 30 Nov 2016 12:53:31 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 84B6E12006B; Wed, 30 Nov 2016 12:53:31 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 12:53:31 +0100 From: To: Geoff Huston Thread-Topic: I-D Action: draft-ietf-lisp-type-iana-04.txt Thread-Index: AQHSSv76g7DUggpH9EuwZacnNO/QKaDxaIQQ Date: Wed, 30 Nov 2016 11:53:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> In-Reply-To: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , Jon Hudson Subject: Re: [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 11:54:43 -0000 Hi Goeff,=20 A new version of the draft is available online. The main changes are: * Change the status to Experimental * Rename the new message and relevant text in the draft to avoid the confus= ion that you raised in your review (LISP is itself is an experimental specification) We didn't change the normative "MUST" in Section 2 because that use is appr= opriate. The "must" you referred to in Section 4 will be removed from the t= ext once the IANA actions are completed.=20 A diff is provided below, fwiw.=20 Let's now if you are OK with this revision. Thank you for the review. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mercredi 30 novembre 2016 12:43 > =C0=A0: i-d-announce@ietf.org > Cc=A0: lisp@ietf.org > Objet=A0: I-D Action: draft-ietf-lisp-type-iana-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol of the > IETF. >=20 > Title : LISP Shared Extension Message & IANA Registry > for LISP Packet Type Allocations > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-ietf-lisp-type-iana-04.txt > Pages : 5 > Date : 2016-11-30 >=20 > Abstract: > This document defines a registry for LISP Packet Type allocations. > It also specifies a LISP shared message type for defining future > extensions and conducting experiments without consuming a LISP packet > type codepoint for each extension. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-lisp-type-iana-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-type-iana-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 30 09:46:44 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBBE1295BD; Wed, 30 Nov 2016 09:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZgh6TrNsLCQ; Wed, 30 Nov 2016 09:46:33 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5533212950D; Wed, 30 Nov 2016 09:46:33 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 3so1935355pgd.0; Wed, 30 Nov 2016 09:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQpU5J22I+WXWtKPkWtzOsNV0lGO6pFGSOIZ2PCDjLg=; b=ljv2kIOd8HGcMENX7nVZwgSff3rUinZVQx7zjYkOjkVGU0gTe4w1OngXb58pJkGLGE zi9mjQPmnN/WwKpRO1j/FdUIf05WY2H6C/MkU6vx3XWi6tBjv43DFGrhA00HiE81qUc2 x8ipdfY+UqxTffZgbX2ykys96kPvTK1svxyfCg/fcvVaIR/Gi7ifr1dtEoTHEcLwUaYW 14bCoKxZPfuYxARxM5k57hCYdUx0d9fZVmJwihPxv83qZUjCukli2D3bYvTxBww3qUx7 BIa6AocOf6t7DQ7hukUN44zvyH1sY4aKH+oxZZnm5o8E6TXpZ2yX5wQI/5DVNLvJt8wF /yOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kQpU5J22I+WXWtKPkWtzOsNV0lGO6pFGSOIZ2PCDjLg=; b=ck0g2G53A17Kxf99tS7eOoYzbpvleuYtd0I45waGxTftO+n0ZXmVQ7QJXJks2uoWnh OThrxjdscZX1oxQtE3q6zVn1xmmsxb/2yqN4k5awpul+x5uSVD8ovqbCSQNPMp0YN8lE lE4PwsX9pr0be5hjWoSuZTSaHkcLqJ/q7yY3EQz8Om2qVGRgQl3mZ87GZ5bzuFChblJN Y/ILkIpJbzeCpia36+A2MNupkagBBKRHeNRqnGalruSwMVvzLXzGDuh7NcmcQh1hdJYq F3z/KwttdeoJ0+PIEafa5r2kAeSMEczqrPI77aiDKsQxlWschRyXG8mVBr+OtWxDKf/D lzGg== X-Gm-Message-State: AKaTC01T0nAwp2P8DPoOC3qO1dV8sxkuKAaP3kPY9y5GnQxI1QRJ8yL96itl4k+ZXDu57g== X-Received: by 10.98.214.20 with SMTP id r20mr34708673pfg.59.1480527992806; Wed, 30 Nov 2016 09:46:32 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id b29sm86701605pgn.48.2016.11.30.09.46.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 09:46:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Dino Farinacci In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 30 Nov 2016 09:46:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , Jon Hudson Subject: Re: [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 17:46:35 -0000 > We didn't change the normative "MUST" in Section 2 because that use is = appropriate. The "must" you referred to in Section 4 will be removed = from the text once the IANA actions are completed.=20 You may want to reference 6830bis and 6833bis documents that will be = standards track. They are individual submissions right now. But the = deadline for objections of making these drafts working group drafts is = this week I think. The draft names will be: draft-ietf-lisp-rfc6830bis-00 draft-ietf-lisp-rfc6833bis-00 Dino From nobody Wed Nov 30 10:28:00 2016 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED148129600 for ; Wed, 30 Nov 2016 10:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.897 X-Spam-Level: X-Spam-Status: No, score=-107.897 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q9pO2VtjA9H for ; Wed, 30 Nov 2016 10:27:54 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D0F12994F for ; Wed, 30 Nov 2016 10:27:53 -0800 (PST) Received: from NXMDA2.org.apnic.net (unknown [2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon) with ESMTPS id b2b065ef-b72a-11e6-8fe1-005056b6f213; Thu, 01 Dec 2016 04:27:50 +1000 (AEST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Dec 2016 04:27:23 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Geoff Huston In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 1 Dec 2016 05:27:47 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <148050619842.6756.13767339984914876536.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933009DC70FB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "rtg-dir@ietf.org" , "Zhangxian \(Xian\)" , "lisp@ietf.org" , "rtg-ads@ietf.org" , "jonathan.hardwick@metaswitch.com" , Jon Hudson Subject: Re: [lisp] I-D Action: draft-ietf-lisp-type-iana-04.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 18:27:57 -0000 Thank you for this revision - this 04 draft appropriately addresses all = of the concerns raised in my review. kind regards, Geoff > On 30 Nov. 2016, at 10:53 pm, = wrote: >=20 > Hi Goeff,=20 >=20 > A new version of the draft is available online. The main changes are: > * Change the status to Experimental > * Rename the new message and relevant text in the draft to avoid the = confusion that you raised in your review (LISP is itself > is an experimental specification) >=20 > We didn't change the normative "MUST" in Section 2 because that use is = appropriate. The "must" you referred to in Section 4 will be removed = from the text once the IANA actions are completed.=20 >=20 > A diff is provided below, fwiw.=20 >=20 > Let's now if you are OK with this revision. >=20 > Thank you for the review. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part = de >> internet-drafts@ietf.org >> Envoy=C3=A9 : mercredi 30 novembre 2016 12:43 >> =C3=80 : i-d-announce@ietf.org >> Cc : lisp@ietf.org >> Objet : I-D Action: draft-ietf-lisp-type-iana-04.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Locator/ID Separation Protocol of = the >> IETF. >>=20 >> Title : LISP Shared Extension Message & IANA = Registry >> for LISP Packet Type Allocations >> Authors : Mohamed Boucadair >> Christian Jacquenet >> Filename : draft-ietf-lisp-type-iana-04.txt >> Pages : 5 >> Date : 2016-11-30 >>=20 >> Abstract: >> This document defines a registry for LISP Packet Type allocations. >> It also specifies a LISP shared message type for defining future >> extensions and conducting experiments without consuming a LISP = packet >> type codepoint for each extension. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-type-iana/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-lisp-type-iana-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-type-iana-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt