Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> If you want to define it as always doing a strict LPM string match on 
> ASCII,that would as you say be well-defined.  It is not what the document 
> says.

I have seen more requirements for exact match, but LPM includes exact match. 
I'm fine with specifying it that way. I'll update spec.

> And it would not solve the collision problem at all.

Right, agree.

Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> The design of LISP explicitly separates the Mapping system from the Itr/EtR.  
> Which means that the "IT Manager configuring xTRs) does not get to define how 
> the mapping system works.

Right, agree, and I didn't say that.

> And if there are undefined variations in how it works for AFI=17, then we 
> have not achieved interoperability.

There isn't. It works exactly like an IPv4 or IPv6 lookup.

> And if there are potential interactions between different uses of AFI=17, 
> then we again have a problem.

There isn't for a given use-case within a given instance-ID. Just like VLANs, 
VRFs, etc. We are not inventing anything new here. We solely want to encode 
ascii strings. 

> If you want to define that AFI-17 is always and only used along with 
> instance-ID, then you solve PART of the problem.  But not all 

Its an EID encoding that can or not go inside an Instance-ID LCAF. And when 
used as an RLOC, there is no instance-ID relationship.

> of it.  If different uses of the AFI clash, then we are creating problems 
> even for a single adminstration using it under a single instance.

IP addresses can clash. We use the same rules for avoiding IP EID clashes as 
AFI=17 clashes. I mentioned this already in a previous email to you.

> And from where I sit, the LISP working group is not chartered to provide a 
> generic string based key-value store.

Look at it this way. Should the IS-IS working group not create hostnames to map 
LSPIDs to names? Allowing this makes it infinitely simpler to manage the 
system. 

This proposal is extremely popular. Ask network operators about IS-IS 
hostnames. This is the same thing. It really is.

Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel Halpern Direct]

The design of LISP explicitly separates the Mapping system from the 
Itr/EtR.  Which means that the "IT Manager configuring xTRs) does not 
get to define how the mapping system works.
And if there are undefined variations in how it works for AFI=17, then 
we have not achieved interoperability.
And if there are potential interactions between different uses of 
AFI=17, then we again have a problem.


If you want to define that AFI-17 is always and only used along with 
instance-ID, then you solve PART of the problem.  But not all of it.  If 
different uses of the AFI clash, then we are creating problems even for 
a single adminstration using it under a single instance.


And from where I sit, the LISP working group is not chartered to provide 
a generic string based key-value store.


Yours,
Joel

On 10/2/2020 12:39 PM, Dino Farinacci wrote:

One can do many things on an ad-hoc basis.
But if we are telling people how to implement mapping systems, we have to tell 
them what they need to do.
And if people are using mapping systems, they have to know what they can expect 
from the mapping system.


Well the way I would deploy this is:

(1) Setup my sites to use AFI=17 the way I decide to use them. (I being the IT 
manager configuring xTRs).
(2) The mapping system allocates me an instance-ID and auth-key that I register 
these EIDs to.
(3) ETRs register AFI=17 with /n (n is the length of the string times 8). ITRs 
request AFI=17 EIDs with /n.

Dino



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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> One can do many things on an ad-hoc basis.
> But if we are telling people how to implement mapping systems, we have to 
> tell them what they need to do.
> And if people are using mapping systems, they have to know what they can 
> expect from the mapping system.

Well the way I would deploy this is:

(1) Setup my sites to use AFI=17 the way I decide to use them. (I being the IT 
manager configuring xTRs).
(2) The mapping system allocates me an instance-ID and auth-key that I register 
these EIDs to.
(3) ETRs register AFI=17 with /n (n is the length of the string times 8). ITRs 
request AFI=17 EIDs with /n.

Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel M. Halpern]

One can do many things on an ad-hoc basis.
But if we are telling people how to implement mapping systems, we have 
to tell them what they need to do.
And if people are using mapping systems, they have to know what they can 
expect from the mapping system.


Yours,
Joel

On 10/2/2020 12:04 PM, Dino Farinacci wrote:

On what basis would the mapping system decide if a full match or prefix match 
is appropriate?  So far, each EID has been specific on what kind of lookup it 
does.  IP (v4 or v6) lookups always do LPM lookups.  All other EIDs we have 
specified so far do exact matches.


Could be a configuration parameter for the instance-ID.

My implementations unconditionally does longest match. But the Map-Requester 
can have exact match when requesting with the same mask-length of the 
registration. Just like /32 IPv4 registrations for VM-mobility.

Dino



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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> On what basis would the mapping system decide if a full match or prefix match 
> is appropriate?  So far, each EID has been specific on what kind of lookup it 
> does.  IP (v4 or v6) lookups always do LPM lookups.  All other EIDs we have 
> specified so far do exact matches.

Could be a configuration parameter for the instance-ID.

My implementations unconditionally does longest match. But the Map-Requester 
can have exact match when requesting with the same mask-length of the 
registration. Just like /32 IPv4 registrations for VM-mobility.

Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel M. Halpern]

On what basis would the mapping system decide if a full match or prefix 
match is appropriate?  So far, each EID has been specific on what kind 
of lookup it does.  IP (v4 or v6) lookups always do LPM lookups.  All 
other EIDs we have specified so far do exact matches.


Yours,
Joel

On 10/2/2020 11:22 AM, Dino Farinacci wrote:

The document looks to me underspecified.


I'm sorry, it is completely specified. I'll respond to a subjective comment 
with a subjective reply.


There is no formal definition of “Distinguished Name”, for what is worth the 
document can be renamed "LISP LCAF String encoding”


I provided a reference in the document to th Address-Family-Identifiers 
document. Where it is listed. That creates the code point. And this document 
says how LISP will use AFI=17.


The slides you presented during IETF 96 suggest that there some longest 
characters match (like longest prefix match but on strings) and this part is 
not documented in the draft.


You can do partial match lookups on strings. If a distinguished-name "luigi" is 
registered as an EID to the mapping system, and a lookup is done on "luigi-iannone", the 
map-server can decide if partial or exact matches are performed. I can make this more clear in the 
document.


As an implementer, the fact that there is no explicit length field is 
worrisome, performance wise.
Because if I need to skip through a LCAF AFI=17 record I have anyway to parse 
the string since I do not know where it ends.
This can slow down operations.


Zero termination of the string creates the length for implementation that can 
support AFI=17. For implementation that do not, it uses the EID mask-length to 
skip over an EID in an EID-record. For RLOC-records if you don't understand an 
AFI, you drop the packet.


I think the draft should include some specific use cases that prove that LCAF 
strings are really useful.


Strings are useful. How they are encoded is another topic.


The ECDSA use case is not a compelling example since you can use LCAF AFI=XX 
that identifies public keys encoded in a specific way (the WG should think 
about proposing such encoding….)


That makes name uses more bytes in the packet. We want to encode a string of 
length 5 in 8 bytes. 2 bytes for AFI and 1 byte null-character. You can encode 
it more efficicently than that. And that is why AFI=17 was chosen.

Dino





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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> The document looks to me underspecified.

I'm sorry, it is completely specified. I'll respond to a subjective comment 
with a subjective reply.

> There is no formal definition of “Distinguished Name”, for what is worth the 
> document can be renamed "LISP LCAF String encoding”

I provided a reference in the document to th Address-Family-Identifiers 
document. Where it is listed. That creates the code point. And this document 
says how LISP will use AFI=17.

> The slides you presented during IETF 96 suggest that there some longest 
> characters match (like longest prefix match but on strings) and this part is 
> not documented in the draft.

You can do partial match lookups on strings. If a distinguished-name "luigi" is 
registered as an EID to the mapping system, and a lookup is done on 
"luigi-iannone", the map-server can decide if partial or exact matches are 
performed. I can make this more clear in the document.

> As an implementer, the fact that there is no explicit length field is 
> worrisome, performance wise.
> Because if I need to skip through a LCAF AFI=17 record I have anyway to parse 
> the string since I do not know where it ends.
> This can slow down operations.

Zero termination of the string creates the length for implementation that can 
support AFI=17. For implementation that do not, it uses the EID mask-length to 
skip over an EID in an EID-record. For RLOC-records if you don't understand an 
AFI, you drop the packet.

> I think the draft should include some specific use cases that prove that LCAF 
> strings are really useful.

Strings are useful. How they are encoded is another topic.

> The ECDSA use case is not a compelling example since you can use LCAF AFI=XX 
> that identifies public keys encoded in a specific way (the WG should think 
> about proposing such encoding….)

That makes name uses more bytes in the packet. We want to encode a string of 
length 5 in 8 bytes. 2 bytes for AFI and 1 byte null-character. You can encode 
it more efficicently than that. And that is why AFI=17 was chosen.

Dino



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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> This document has been sitting around for 4 years indeed, but it has been 
> presented to the WG for discussion only during IETF 96 (Summer 2016).
> https://www.ietf.org/proceedings/96/lisp.html
> The presentation was only 2 slides long and had no comments (you can check 
> the minutes).

Because it is that simple and nothing has changed in the document.

> No discussions have being going on ever since, neither in the mailing list 
> nor during face to face meetings.

Because people support it. You saw that on the mailing list. Joel just had 
recent comments, and they surfaced because of my initial email. He wanted 
clarity in the document. So I will make another revision.

> You have all rights to ask for adoption, but not to formally open the call 
> for adoption.

I don't have authority to formally do anything. I sent an email *requesting* 
adoption. I cannot mandate it as an individual. You chairs know that.

> IETF procedures want that is up to the chairs to open the adoption call.
> Even so, your _informal_ call for adoption has raised 2 supports and 1 
> objection.

There were more than 2 supports emails. And you said "formal" above and now you 
said "informal". So the labels are not helpful.

> At this stage there are no sufficient elements that allow the chairs to 
> declare consensus for adoption.

Well I will let the working group speak. So I would request the group to post 
on this list and show even more support.

> What I would suggest is:
> - to continue the technical discussion on the mailing list 
>   - the more the better

Agree. But how much is enough is the question.

> -  present the document during one of the next meetings

Sure.

>   - Please focus on why this is needed from a technical standpoint. Just 
> stating I use it in another document is not a technical reason.

The drafts that reference it provide technical material.

> - If at that point there is interest from the WG, we will make the 
> call for adoption.

There is interest. I don't know what more you want.

> I encourage you all to continue the discussion.

And I encourage you chairs to be open minded. And allow the working group to be 
creative and productive.

Dino


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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Luigi Iannone]

Dino,

Speaking as an individual (not as a chair) I have few technical comments on the 
document.

 

The document looks to me underspecified.
There is no formal definition of “Distinguished Name”, for what is worth the 
document can be renamed "LISP LCAF String encoding”
The slides you presented during IETF 96 suggest that there some longest 
characters match (like longest prefix match but on strings) and this part is 
not documented in the draft.
As an implementer, the fact that there is no explicit length field is 
worrisome, performance wise.
Because if I need to skip through a LCAF AFI=17 record I have anyway to parse 
the string since I do not know where it ends.
This can slow down operations.
I think the draft should include some specific use cases that prove that LCAF 
strings are really useful.
The ECDSA use case is not a compelling example since you can use LCAF AFI=XX 
that identifies public keys encoded in a specific way (the WG should think 
about proposing such encoding….)


Ciao

L.



> On 29 Sep 2020, at 22:58, Dino Farinacci  wrote:
> 
> So since there seems to be support and little or no objections, can we make 
> this draft a working group document and continue the discussion. I can add 
> more text to reflect Joel’s comments. 
> 
> Thanks for the comments and discussion Joel. 
> 
> Dino
> 
>> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern  wrote:
>> 
>> Another way of looking at my issue here is the many problems the DNS folks 
>> have had with tXT records.  They are free-form text.  Making them useful has 
>> proven to be a major challenge.  hence, even as RLOCs rather than EIDs 
>> (where the collision problem is not an issue), I am concerned that adding 
>> this is opening a can of worms.
>> 
>> Yours,
>> Joel
>> 
>> PS: Dino, youa re correct that the hash probably won't collide with anything 
>> else.  But for anything that is not cryptographically random, collision 
>> seems a major risk.
>> 
>> PPS: Even for you hash case, you concluded that you needed a type 
>> discriminator (hash:).  Presumably so taht you would know which one you 
>> needed for the ECDSA operation.  Sensible.  But if we need that, probably 
>> eveyrone needs that.  At which point it should be part of the definition.  
>> At which point we get into defining the structure of these naems with 
>> sufficient uniqueness.  Or sub-typing,  Or something.
>> 
>> On 9/29/2020 3:58 PM, Dino Farinacci wrote:
 I think it really needs more structure.  One does not say "here is a 
 shared database; use any key you like and hope not to collide with other 
 users."
>>> I can add that to the draft.
 
>> If there is to be standard usage of this, and if there is to be more 
>> than one such usage, how are collisions avoided?  It is not sufficient 
>> to say "just don't" as different problems may end up needing overlapping 
>> name spaces.  The hash usage (below) assumes that the solution is to 
>> prepend the string "hash:' on the front.  But that is not formally 
>> defined, and as such is not actually a reliable mechanism.
>> (Frankly, for the hashes I would prefer to use a different EID LCAF that 
>> carries the binary hash.)
> The ecdsa-auth use-case assumes that the hash length is largest where 
> collisions won’t happen. There are applications that use UUIDs and 
> encodes them in distinguished-name EIDs. UUIDs do not have an allocation 
> authority. And:
 
 the ECDSA draft assumes that no other uses will begin with hash:.  This 
 has nothing to do with length.  My concern is not collision amon hashes.  
 It is collision between hashes and other uses of the "distinguished name" 
 LCAF.
>>> If the hash avoids collisions, then anything you put before it, in totality 
>>> makes the name unique.
 I suspect that the people supporting this have expectations on how this 
 will work.  But it seems sufficiently basic that the semantics, rather 
 than the encoding, is where I would expect the WG to start.  Encodings are 
 easy.
> So lets have a look at each Internet Draft that references 
> draft-farinacci-lisp-name-encoding and lets review those semantic 
> encodings.
 
 Looking at the couple of places you have chosen to use this, and have 
 therefore been careful not to collide with yourself really does not tell 
 us much.
>>> If you connect two IPv4 islands behind NATs and register their addresses to 
>>> the same instance-ID to the same mapping system, those addresses will 
>>> collide. The same goes for these names. That is what VPNs are used for and 
>>> hence instance-IDs allows the registering entities to agree to not collide 
>>> names.
>>> This is a general principle for the LISP mapping system for all EIDs being 
>>> used. And note for RLOC-names, they do not have to be unique. They are 
>>> free-form documentation based names.
 If you want a sub-type under LCAF, then let's do that.  trying 

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Luigi Iannone]

Dino,

This document has been sitting around for 4 years indeed, but it has been 
presented to the WG for discussion only during IETF 96 (Summer 2016).
https://www.ietf.org/proceedings/96/lisp.html 

The presentation was only 2 slides long and had no comments (you can check the 
minutes).

No discussions have being going on ever since, neither in the mailing list nor 
during face to face meetings.

You have all rights to ask for adoption, but not to formally open the call for 
adoption.
IETF procedures want that is up to the chairs to open the adoption call.
Even so, your _informal_ call for adoption has raised 2 supports and 1 
objection.

At this stage there are no sufficient elements that allow the chairs to declare 
consensus for adoption.

What I would suggest is:
- to continue the technical discussion on the mailing list 
- the more the better
-  present the document during one of the next meetings
- Please focus on why this is needed from a technical standpoint. Just 
stating I use it in another document is not a technical reason.
- If at that point there is interest from the WG, we will make the call 
for adoption.

I encourage you all to continue the discussion.

Ciao

Luigi



> On 1 Oct 2020, at 05:04, Dino Farinacci  wrote:
> 
> Well chairs - can you make a decision?
> 
> Dino
> 
>> On Sep 29, 2020, at 1:58 PM, Dino Farinacci  wrote:
>> 
>> So since there seems to be support and little or no objections, can we make 
>> this draft a working group document and continue the discussion. I can add 
>> more text to reflect Joel’s comments. 
>> 
>> Thanks for the comments and discussion Joel. 
>> 
>> Dino
>> 
>>> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern  wrote:
>>> 
>>> Another way of looking at my issue here is the many problems the DNS folks 
>>> have had with tXT records.  They are free-form text.  Making them useful 
>>> has proven to be a major challenge.  hence, even as RLOCs rather than EIDs 
>>> (where the collision problem is not an issue), I am concerned that adding 
>>> this is opening a can of worms.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> PS: Dino, youa re correct that the hash probably won't collide with 
>>> anything else.  But for anything that is not cryptographically random, 
>>> collision seems a major risk.
>>> 
>>> PPS: Even for you hash case, you concluded that you needed a type 
>>> discriminator (hash:).  Presumably so taht you would know which one you 
>>> needed for the ECDSA operation.  Sensible.  But if we need that, probably 
>>> eveyrone needs that.  At which point it should be part of the definition.  
>>> At which point we get into defining the structure of these naems with 
>>> sufficient uniqueness.  Or sub-typing,  Or something.
>>> 
>>> On 9/29/2020 3:58 PM, Dino Farinacci wrote:
> I think it really needs more structure.  One does not say "here is a 
> shared database; use any key you like and hope not to collide with other 
> users."
 I can add that to the draft.
> 
>>> If there is to be standard usage of this, and if there is to be more 
>>> than one such usage, how are collisions avoided?  It is not sufficient 
>>> to say "just don't" as different problems may end up needing 
>>> overlapping name spaces.  The hash usage (below) assumes that the 
>>> solution is to prepend the string "hash:' on the front.  But that is 
>>> not formally defined, and as such is not actually a reliable mechanism.
>>> (Frankly, for the hashes I would prefer to use a different EID LCAF 
>>> that carries the binary hash.)
>> The ecdsa-auth use-case assumes that the hash length is largest where 
>> collisions won’t happen. There are applications that use UUIDs and 
>> encodes them in distinguished-name EIDs. UUIDs do not have an allocation 
>> authority. And:
> 
> the ECDSA draft assumes that no other uses will begin with hash:.  This 
> has nothing to do with length.  My concern is not collision amon hashes.  
> It is collision between hashes and other uses of the "distinguished name" 
> LCAF.
 If the hash avoids collisions, then anything you put before it, in 
 totality makes the name unique.
> I suspect that the people supporting this have expectations on how this 
> will work.  But it seems sufficiently basic that the semantics, rather 
> than the encoding, is where I would expect the WG to start.  Encodings 
> are easy.
>> So lets have a look at each Internet Draft that references 
>> draft-farinacci-lisp-name-encoding and lets review those semantic 
>> encodings.
> 
> Looking at the couple of places you have chosen to use this, and have 
> therefore been careful not to collide with yourself really does not tell 
> us much.
 If you connect two IPv4 islands behind NATs and register their addresses 
 to the same instance-ID to the same mapping system, those addresses 

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

Well chairs - can you make a decision?

Dino

> On Sep 29, 2020, at 1:58 PM, Dino Farinacci  wrote:
> 
> So since there seems to be support and little or no objections, can we make 
> this draft a working group document and continue the discussion. I can add 
> more text to reflect Joel’s comments. 
> 
> Thanks for the comments and discussion Joel. 
> 
> Dino
> 
>> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern  wrote:
>> 
>> Another way of looking at my issue here is the many problems the DNS folks 
>> have had with tXT records.  They are free-form text.  Making them useful has 
>> proven to be a major challenge.  hence, even as RLOCs rather than EIDs 
>> (where the collision problem is not an issue), I am concerned that adding 
>> this is opening a can of worms.
>> 
>> Yours,
>> Joel
>> 
>> PS: Dino, youa re correct that the hash probably won't collide with anything 
>> else.  But for anything that is not cryptographically random, collision 
>> seems a major risk.
>> 
>> PPS: Even for you hash case, you concluded that you needed a type 
>> discriminator (hash:).  Presumably so taht you would know which one you 
>> needed for the ECDSA operation.  Sensible.  But if we need that, probably 
>> eveyrone needs that.  At which point it should be part of the definition.  
>> At which point we get into defining the structure of these naems with 
>> sufficient uniqueness.  Or sub-typing,  Or something.
>> 
>> On 9/29/2020 3:58 PM, Dino Farinacci wrote:
 I think it really needs more structure.  One does not say "here is a 
 shared database; use any key you like and hope not to collide with other 
 users."
>>> I can add that to the draft.
 
>> If there is to be standard usage of this, and if there is to be more 
>> than one such usage, how are collisions avoided?  It is not sufficient 
>> to say "just don't" as different problems may end up needing overlapping 
>> name spaces.  The hash usage (below) assumes that the solution is to 
>> prepend the string "hash:' on the front.  But that is not formally 
>> defined, and as such is not actually a reliable mechanism.
>> (Frankly, for the hashes I would prefer to use a different EID LCAF that 
>> carries the binary hash.)
> The ecdsa-auth use-case assumes that the hash length is largest where 
> collisions won’t happen. There are applications that use UUIDs and 
> encodes them in distinguished-name EIDs. UUIDs do not have an allocation 
> authority. And:
 
 the ECDSA draft assumes that no other uses will begin with hash:.  This 
 has nothing to do with length.  My concern is not collision amon hashes.  
 It is collision between hashes and other uses of the "distinguished name" 
 LCAF.
>>> If the hash avoids collisions, then anything you put before it, in totality 
>>> makes the name unique.
 I suspect that the people supporting this have expectations on how this 
 will work.  But it seems sufficiently basic that the semantics, rather 
 than the encoding, is where I would expect the WG to start.  Encodings are 
 easy.
> So lets have a look at each Internet Draft that references 
> draft-farinacci-lisp-name-encoding and lets review those semantic 
> encodings.
 
 Looking at the couple of places you have chosen to use this, and have 
 therefore been careful not to collide with yourself really does not tell 
 us much.
>>> If you connect two IPv4 islands behind NATs and register their addresses to 
>>> the same instance-ID to the same mapping system, those addresses will 
>>> collide. The same goes for these names. That is what VPNs are used for and 
>>> hence instance-IDs allows the registering entities to agree to not collide 
>>> names.
>>> This is a general principle for the LISP mapping system for all EIDs being 
>>> used. And note for RLOC-names, they do not have to be unique. They are 
>>> free-form documentation based names.
 If you want a sub-type under LCAF, then let's do that.  trying to pretend 
 arbitrary strings have distinguishable semantics is asking for trouble.
>>> The AFI encoding is tigher and save less space in the packet and hence why 
>>> it was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm 
>>> sure many coders appreceiate this.
>>> Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

So since there seems to be support and little or no objections, can we make 
this draft a working group document and continue the discussion. I can add more 
text to reflect Joel’s comments. 

Thanks for the comments and discussion Joel. 

Dino

> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern  wrote:
> 
> Another way of looking at my issue here is the many problems the DNS folks 
> have had with tXT records.  They are free-form text.  Making them useful has 
> proven to be a major challenge.  hence, even as RLOCs rather than EIDs (where 
> the collision problem is not an issue), I am concerned that adding this is 
> opening a can of worms.
> 
> Yours,
> Joel
> 
> PS: Dino, youa re correct that the hash probably won't collide with anything 
> else.  But for anything that is not cryptographically random, collision seems 
> a major risk.
> 
> PPS: Even for you hash case, you concluded that you needed a type 
> discriminator (hash:).  Presumably so taht you would know which one you 
> needed for the ECDSA operation.  Sensible.  But if we need that, probably 
> eveyrone needs that.  At which point it should be part of the definition.  At 
> which point we get into defining the structure of these naems with sufficient 
> uniqueness.  Or sub-typing,  Or something.
> 
> On 9/29/2020 3:58 PM, Dino Farinacci wrote:
>>> I think it really needs more structure.  One does not say "here is a shared 
>>> database; use any key you like and hope not to collide with other users."
>> I can add that to the draft.
>>> 
> If there is to be standard usage of this, and if there is to be more than 
> one such usage, how are collisions avoided?  It is not sufficient to say 
> "just don't" as different problems may end up needing overlapping name 
> spaces.  The hash usage (below) assumes that the solution is to prepend 
> the string "hash:' on the front.  But that is not formally defined, and 
> as such is not actually a reliable mechanism.
> (Frankly, for the hashes I would prefer to use a different EID LCAF that 
> carries the binary hash.)
 The ecdsa-auth use-case assumes that the hash length is largest where 
 collisions won’t happen. There are applications that use UUIDs and encodes 
 them in distinguished-name EIDs. UUIDs do not have an allocation 
 authority. And:
>>> 
>>> the ECDSA draft assumes that no other uses will begin with hash:.  This has 
>>> nothing to do with length.  My concern is not collision amon hashes.  It is 
>>> collision between hashes and other uses of the "distinguished name" LCAF.
>> If the hash avoids collisions, then anything you put before it, in totality 
>> makes the name unique.
>>> I suspect that the people supporting this have expectations on how this 
>>> will work.  But it seems sufficiently basic that the semantics, rather than 
>>> the encoding, is where I would expect the WG to start.  Encodings are easy.
 So lets have a look at each Internet Draft that references 
 draft-farinacci-lisp-name-encoding and lets review those semantic 
 encodings.
>>> 
>>> Looking at the couple of places you have chosen to use this, and have 
>>> therefore been careful not to collide with yourself really does not tell us 
>>> much.
>> If you connect two IPv4 islands behind NATs and register their addresses to 
>> the same instance-ID to the same mapping system, those addresses will 
>> collide. The same goes for these names. That is what VPNs are used for and 
>> hence instance-IDs allows the registering entities to agree to not collide 
>> names.
>> This is a general principle for the LISP mapping system for all EIDs being 
>> used. And note for RLOC-names, they do not have to be unique. They are 
>> free-form documentation based names.
>>> If you want a sub-type under LCAF, then let's do that.  trying to pretend 
>>> arbitrary strings have distinguishable semantics is asking for trouble.
>> The AFI encoding is tigher and save less space in the packet and hence why 
>> it was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm 
>> sure many coders appreceiate this.
>> Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

Well I have seen these sorts of issues come up before and it usually is not as 
bad as designers think they are. In practice, people make up there own rules 
and out checks and balances in to verify collisions. 

Dino

> On Sep 29, 2020, at 1:23 PM, Joel M. Halpern  wrote:
> 
> Another way of looking at my issue here is the many problems the DNS folks 
> have had with tXT records.  They are free-form text.  Making them useful has 
> proven to be a major challenge.  hence, even as RLOCs rather than EIDs (where 
> the collision problem is not an issue), I am concerned that adding this is 
> opening a can of worms.
> 
> Yours,
> Joel
> 
> PS: Dino, youa re correct that the hash probably won't collide with anything 
> else.  But for anything that is not cryptographically random, collision seems 
> a major risk.
> 
> PPS: Even for you hash case, you concluded that you needed a type 
> discriminator (hash:).  Presumably so taht you would know which one you 
> needed for the ECDSA operation.  Sensible.  But if we need that, probably 
> eveyrone needs that.  At which point it should be part of the definition.  At 
> which point we get into defining the structure of these naems with sufficient 
> uniqueness.  Or sub-typing,  Or something.
> 
> On 9/29/2020 3:58 PM, Dino Farinacci wrote:
>>> I think it really needs more structure.  One does not say "here is a shared 
>>> database; use any key you like and hope not to collide with other users."
>> I can add that to the draft.
>>> 
> If there is to be standard usage of this, and if there is to be more than 
> one such usage, how are collisions avoided?  It is not sufficient to say 
> "just don't" as different problems may end up needing overlapping name 
> spaces.  The hash usage (below) assumes that the solution is to prepend 
> the string "hash:' on the front.  But that is not formally defined, and 
> as such is not actually a reliable mechanism.
> (Frankly, for the hashes I would prefer to use a different EID LCAF that 
> carries the binary hash.)
 The ecdsa-auth use-case assumes that the hash length is largest where 
 collisions won’t happen. There are applications that use UUIDs and encodes 
 them in distinguished-name EIDs. UUIDs do not have an allocation 
 authority. And:
>>> 
>>> the ECDSA draft assumes that no other uses will begin with hash:.  This has 
>>> nothing to do with length.  My concern is not collision amon hashes.  It is 
>>> collision between hashes and other uses of the "distinguished name" LCAF.
>> If the hash avoids collisions, then anything you put before it, in totality 
>> makes the name unique.
>>> I suspect that the people supporting this have expectations on how this 
>>> will work.  But it seems sufficiently basic that the semantics, rather than 
>>> the encoding, is where I would expect the WG to start.  Encodings are easy.
 So lets have a look at each Internet Draft that references 
 draft-farinacci-lisp-name-encoding and lets review those semantic 
 encodings.
>>> 
>>> Looking at the couple of places you have chosen to use this, and have 
>>> therefore been careful not to collide with yourself really does not tell us 
>>> much.
>> If you connect two IPv4 islands behind NATs and register their addresses to 
>> the same instance-ID to the same mapping system, those addresses will 
>> collide. The same goes for these names. That is what VPNs are used for and 
>> hence instance-IDs allows the registering entities to agree to not collide 
>> names.
>> This is a general principle for the LISP mapping system for all EIDs being 
>> used. And note for RLOC-names, they do not have to be unique. They are 
>> free-form documentation based names.
>>> If you want a sub-type under LCAF, then let's do that.  trying to pretend 
>>> arbitrary strings have distinguishable semantics is asking for trouble.
>> The AFI encoding is tigher and save less space in the packet and hence why 
>> it was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm 
>> sure many coders appreceiate this.
>> Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel M. Halpern]

Another way of looking at my issue here is the many problems the DNS 
folks have had with tXT records.  They are free-form text.  Making them 
useful has proven to be a major challenge.  hence, even as RLOCs rather 
than EIDs (where the collision problem is not an issue), I am concerned 
that adding this is opening a can of worms.


Yours,
Joel

PS: Dino, youa re correct that the hash probably won't collide with 
anything else.  But for anything that is not cryptographically random, 
collision seems a major risk.


PPS: Even for you hash case, you concluded that you needed a type 
discriminator (hash:).  Presumably so taht you would know which one you 
needed for the ECDSA operation.  Sensible.  But if we need that, 
probably eveyrone needs that.  At which point it should be part of the 
definition.  At which point we get into defining the structure of these 
naems with sufficient uniqueness.  Or sub-typing,  Or something.


On 9/29/2020 3:58 PM, Dino Farinacci wrote:

I think it really needs more structure.  One does not say "here is a shared 
database; use any key you like and hope not to collide with other users."


I can add that to the draft.




If there is to be standard usage of this, and if there is to be more than one such usage, how 
are collisions avoided?  It is not sufficient to say "just don't" as different 
problems may end up needing overlapping name spaces.  The hash usage (below) assumes that the 
solution is to prepend the string "hash:' on the front.  But that is not formally 
defined, and as such is not actually a reliable mechanism.
(Frankly, for the hashes I would prefer to use a different EID LCAF that 
carries the binary hash.)

The ecdsa-auth use-case assumes that the hash length is largest where 
collisions won’t happen. There are applications that use UUIDs and encodes them 
in distinguished-name EIDs. UUIDs do not have an allocation authority. And:


the ECDSA draft assumes that no other uses will begin with hash:.  This has nothing to do 
with length.  My concern is not collision amon hashes.  It is collision between hashes 
and other uses of the "distinguished name" LCAF.


If the hash avoids collisions, then anything you put before it, in totality 
makes the name unique.


I suspect that the people supporting this have expectations on how this will 
work.  But it seems sufficiently basic that the semantics, rather than the 
encoding, is where I would expect the WG to start.  Encodings are easy.

So lets have a look at each Internet Draft that references 
draft-farinacci-lisp-name-encoding and lets review those semantic encodings.


Looking at the couple of places you have chosen to use this, and have therefore 
been careful not to collide with yourself really does not tell us much.


If you connect two IPv4 islands behind NATs and register their addresses to the 
same instance-ID to the same mapping system, those addresses will collide. The 
same goes for these names. That is what VPNs are used for and hence 
instance-IDs allows the registering entities to agree to not collide names.

This is a general principle for the LISP mapping system for all EIDs being 
used. And note for RLOC-names, they do not have to be unique. They are 
free-form documentation based names.


If you want a sub-type under LCAF, then let's do that.  trying to pretend 
arbitrary strings have distinguishable semantics is asking for trouble.


The AFI encoding is tigher and save less space in the packet and hence why it 
was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm sure 
many coders appreceiate this.

Dino



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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> I think it really needs more structure.  One does not say "here is a shared 
> database; use any key you like and hope not to collide with other users."

I can add that to the draft.

> 
>>> If there is to be standard usage of this, and if there is to be more than 
>>> one such usage, how are collisions avoided?  It is not sufficient to say 
>>> "just don't" as different problems may end up needing overlapping name 
>>> spaces.  The hash usage (below) assumes that the solution is to prepend the 
>>> string "hash:' on the front.  But that is not formally defined, and as such 
>>> is not actually a reliable mechanism.
>>> (Frankly, for the hashes I would prefer to use a different EID LCAF that 
>>> carries the binary hash.)
>> The ecdsa-auth use-case assumes that the hash length is largest where 
>> collisions won’t happen. There are applications that use UUIDs and encodes 
>> them in distinguished-name EIDs. UUIDs do not have an allocation authority. 
>> And:
> 
> the ECDSA draft assumes that no other uses will begin with hash:.  This has 
> nothing to do with length.  My concern is not collision amon hashes.  It is 
> collision between hashes and other uses of the "distinguished name" LCAF.

If the hash avoids collisions, then anything you put before it, in totality 
makes the name unique.

> I suspect that the people supporting this have expectations on how this will 
> work.  But it seems sufficiently basic that the semantics, rather than the 
> encoding, is where I would expect the WG to start.  Encodings are easy.
>> So lets have a look at each Internet Draft that references 
>> draft-farinacci-lisp-name-encoding and lets review those semantic encodings.
> 
> Looking at the couple of places you have chosen to use this, and have 
> therefore been careful not to collide with yourself really does not tell us 
> much.

If you connect two IPv4 islands behind NATs and register their addresses to the 
same instance-ID to the same mapping system, those addresses will collide. The 
same goes for these names. That is what VPNs are used for and hence 
instance-IDs allows the registering entities to agree to not collide names. 

This is a general principle for the LISP mapping system for all EIDs being 
used. And note for RLOC-names, they do not have to be unique. They are 
free-form documentation based names.

> If you want a sub-type under LCAF, then let's do that.  trying to pretend 
> arbitrary strings have distinguishable semantics is asking for trouble.

The AFI encoding is tigher and save less space in the packet and hence why it 
was chosen. Plus if you use it in LCAFs, there is less LCAF nesting. I'm sure 
many coders appreceiate this.

Dino

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel M. Halpern]

In line, preserving all for now, but we will need to trim or top-post soon.
Yours,
Joel

On 9/29/2020 3:42 PM, Dino Farinacci wrote:
Looking again at this draft, and at the example Dino points to, I 
think there is a basic problem with the work and the usage.


the problem is not a problem for the mapping system per se.  It is a 
problem for usage.


The draft does not define any mechanism for structuring, allocating, 
or otherwise managing the space of names.  It does not say "URIs".  It 
does not say "DNS names"  It syas "ASCII string, terminated by 0".


Because it is designed as a non-structured field where a deployment can 
decide what the structure is based on the mapping system it uses, or the 
instance-ID within a mapping system it uses.


The draft’s intent is to define a general encoding for LISP messages. 
How it will be used is left to other documents.


I think it really needs more structure.  One does not say "here is a 
shared database; use any key you like and hope not to collide with other 
users."




If there is to be standard usage of this, and if there is to be more 
than one such usage, how are collisions avoided?  It is not sufficient 
to say "just don't" as different problems may end up needing 
overlapping name spaces.  The hash usage (below) assumes that the 
solution is to prepend the string "hash:' on the front.  But that is 
not formally defined, and as such is not actually a reliable mechanism.
(Frankly, for the hashes I would prefer to use a different EID LCAF 
that carries the binary hash.)


The ecdsa-auth use-case assumes that the hash length is largest where 
collisions won’t happen. There are applications that use UUIDs and 
encodes them in distinguished-name EIDs. UUIDs do not have an allocation 
authority. And:


the ECDSA draft assumes that no other uses will begin with hash:.  This 
has nothing to do with length.  My concern is not collision amon hashes. 
 It is collision between hashes and other uses of the "distinguished 
name" LCAF.


Note that most uses in the industry for the last 40 yeaars of 
"distinguished name" have gone to some length to be clear how names are 
distinguished.  This does not.  That is what causes me concern.





I suspect that the people supporting this have expectations on how 
this will work.  But it seems sufficiently basic that the semantics, 
rather than the encoding, is where I would expect the WG to start. 
 Encodings are easy.


So lets have a look at each Internet Draft that 
references draft-farinacci-lisp-name-encoding and lets review those 
semantic encodings.


Looking at the couple of places you have chosen to use this, and have 
therefore been careful not to collide with yourself really does not tell 
us much.


If you want a sub-type under LCAF, then let's do that.  trying to 
pretend arbitrary strings have distinguishable semantics is asking for 
trouble.




For draft-farinacci-lisp-simple-nat-00, the RLOCs are encoded with human 
readable RLOC-names so you can distinguish a multi-homed interface 
through NATs. That has proved useful for my lispers.net 
 implementation.


I will also acknowledge that as chair I have concerns about turning 
LISP into an arbitrary database system.  Our charter is a mapping 
system in support of routing.  I understand why the ECDSA keys need to 
be in there.  But I do not want to fall into the BGP trap of trying to 
solve every problem with the hammer in my hand.


I could encode anything I want in an IPv6 EID and make the LISP mapping 
system an arbitrary database. I don’t think anyone wants to do this. The 
mapping system is used for routing, addressing, identity, and location 
problems (at the network layer).


Dino



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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel M. Halpern]

Looking again at this draft, and at the example Dino points to, I think 
there is a basic problem with the work and the usage.


the problem is not a problem for the mapping system per se.  It is a 
problem for usage.


The draft does not define any mechanism for structuring, allocating, or 
otherwise managing the space of names.  It does not say "URIs".  It does 
not say "DNS names"  It syas "ASCII string, terminated by 0".


If there is to be standard usage of this, and if there is to be more 
than one such usage, how are collisions avoided?  It is not sufficient 
to say "just don't" as different problems may end up needing overlapping 
name spaces.  The hash usage (below) assumes that the solution is to 
prepend the string "hash:' on the front.  But that is not formally 
defined, and as such is not actually a reliable mechanism.
(Frankly, for the hashes I would prefer to use a different EID LCAF that 
carries the binary hash.)


I suspect that the people supporting this have expectations on how this 
will work.  But it seems sufficiently basic that the semantics, rather 
than the encoding, is where I would expect the WG to start.  Encodings 
are easy.


I will also acknowledge that as chair I have concerns about turning LISP 
into an arbitrary database system.  Our charter is a mapping system in 
support of routing.  I understand why the ECDSA keys need to be in 
there.  But I do not want to fall into the BGP trap of trying to solve 
every problem with the hammer in my hand.


Yours,
Joel

On 9/28/2020 10:48 AM, Dino Farinacci wrote:

As chair, I would really like to see something more than just +1.  For example, 
what do you see this as being useful for?


There are several Internet Drafts that show uses for distinguished names. Case 
in point is the draft-ietf-lisp-ecdsa-auth working group Internet Draft.

And as Albert said for labeling RLOCs. It makes it easier for operators to run 
and debug the overlay system.

Dino




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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

> As chair, I would really like to see something more than just +1.  For 
> example, what do you see this as being useful for?

There are several Internet Drafts that show uses for distinguished names. Case 
in point is the draft-ietf-lisp-ecdsa-auth working group Internet Draft. 

And as Albert said for labeling RLOCs. It makes it easier for operators to run 
and debug the overlay system. 

Dino


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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Albert López]

I believe that using a label as an EID/RLOC can be really useful and 
give extra flexibility to LISP. For instance requesting a service by 
name or providing extra information of an EID or RLOC.


Regards

Albert

On 28/9/20 7:57, Joel M. Halpern wrote:
As chair, I would really like to see something more than just +1. For 
example, what do you see this as being useful for?


Yours,
Joel

On 9/28/2020 1:29 AM, Albert López wrote:

+1

Albert L.

On 27/9/20 9:36, Dino Farinacci wrote:
I did not see any objections for this request but I didn’t see any 
specific support either. Can we get some replies if you support 
this. Otherwise, it will continue to reside for more than 4 years as 
an individual submission.


Thanks in advance,
Dino

On Sep 14, 2020, at 11:49 AM, Dino Farinacci > wrote:




I would like to make this individual submission a working group 
document. I’d like to hear if there are any objections. And then I 
would like it to start a WG last call.


The document is a simple encoding of an ASCII string for an EID or 
RLOC record using AFI=17 (distinguished-name). It has been active 
since 2016. I believe its time to do something with it.


Thanks in advance,
Dino



___
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



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



--
Albert López
CCABA System Administrator
Universitat Politècnica de Catalunya
Telf: 93 4017182

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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Joel M. Halpern]

As chair, I would really like to see something more than just +1.  For 
example, what do you see this as being useful for?


Yours,
Joel

On 9/28/2020 1:29 AM, Albert López wrote:

+1

Albert L.

On 27/9/20 9:36, Dino Farinacci wrote:
I did not see any objections for this request but I didn’t see any 
specific support either. Can we get some replies if you support this. 
Otherwise, it will continue to reside for more than 4 years as an 
individual submission.


Thanks in advance,
Dino

On Sep 14, 2020, at 11:49 AM, Dino Farinacci > wrote:




I would like to make this individual submission a working group 
document. I’d like to hear if there are any objections. And then I 
would like it to start a WG last call.


The document is a simple encoding of an ASCII string for an EID or 
RLOC record using AFI=17 (distinguished-name). It has been active 
since 2016. I believe its time to do something with it.


Thanks in advance,
Dino



___
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



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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Albert López]

+1

Albert L.

On 27/9/20 9:36, Dino Farinacci wrote:
I did not see any objections for this request but I didn’t see any 
specific support either. Can we get some replies if you support this. 
Otherwise, it will continue to reside for more than 4 years as an 
individual submission.


Thanks in advance,
Dino

On Sep 14, 2020, at 11:49 AM, Dino Farinacci > wrote:




I would like to make this individual submission a working group 
document. I’d like to hear if there are any objections. And then I 
would like it to start a WG last call.


The document is a simple encoding of an ASCII string for an EID or 
RLOC record using AFI=17 (distinguished-name). It has been active 
since 2016. I believe its time to do something with it.


Thanks in advance,
Dino



___
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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Lori Jakab (lojakab)]

On Sep 27, 2020, at 9:36 AM, Dino Farinacci  wrote:
> 
> I did not see any objections for this request but I didn’t see any specific 
> support either. Can we get some replies if you support this. Otherwise, it 
> will continue to reside for more than 4 years as an individual submission.

I’m supporting the draft to become a WG document.

-Lori

> 
> Thanks in advance,
> Dino
> 
>> On Sep 14, 2020, at 11:49 AM, Dino Farinacci > > wrote:
>> 
>> 
>> 
> 
>> 
>> I would like to make this individual submission a working group document. 
>> I’d like to hear if there are any objections. And then I would like it to 
>> start a WG last call.
>> 
>> The document is a simple encoding of an ASCII string for an EID or RLOC 
>> record using AFI=17 (distinguished-name). It has been active since 2016. I 
>> believe its time to do something with it.
>> 
>> Thanks in advance,
>> Dino
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp



smime.p7s
Description: S/MIME cryptographic signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Sharon]

Support.

--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Sep 27, 2020, at 10:36, Dino Farinacci  wrote:
> 
> I did not see any objections for this request but I didn’t see any specific 
> support either. Can we get some replies if you support this. Otherwise, it 
> will continue to reside for more than 4 years as an individual submission.
> 
> Thanks in advance,
> Dino
> 
>> On Sep 14, 2020, at 11:49 AM, Dino Farinacci  wrote:
>> 
>> 
>> 
> 
>> I would like to make this individual submission a working group document. 
>> I’d like to hear if there are any objections. And then I would like it to 
>> start a WG last call.
>> 
>> The document is a simple encoding of an ASCII string for an EID or RLOC 
>> record using AFI=17 (distinguished-name). It has been active since 2016. I 
>> believe its time to do something with it.
>> 
>> Thanks in advance,
>> Dino
> 
> ___
> 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

Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

I did not see any objections for this request but I didn’t see any specific 
support either. Can we get some replies if you support this. Otherwise, it will 
continue to reside for more than 4 years as an individual submission.

Thanks in advance,
Dino

> On Sep 14, 2020, at 11:49 AM, Dino Farinacci  wrote:
> 
> 
> 
> 
> I would like to make this individual submission a working group document. I’d 
> like to hear if there are any objections. And then I would like it to start a 
> WG last call.
> 
> The document is a simple encoding of an ASCII string for an EID or RLOC 
> record using AFI=17 (distinguished-name). It has been active since 2016. I 
> believe its time to do something with it.
> 
> Thanks in advance,
> Dino

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

[lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci]

I would like to make this individual submission a working group document. I’d 
like to hear if there are any objections. And then I would like it to start a 
WG last call.

The document is a simple encoding of an ASCII string for an EID or RLOC record 
using AFI=17 (distinguished-name). It has been active since 2016. I believe its 
time to do something with it.

Thanks in advance,
Dino___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp