[lisp] Re: Roman Danyliw's No Objection on draft-ietf-lisp-name-encoding-09: (with COMMENT)

[Dino Farinacci <[e-mail]>]

> Thank you to Jouni Korhonen for the GENART review.

And thank you Roman for your review.

> ** Section 3
>   When Distinguished Names are encoded for EIDs, the EID-Prefix length
>   of the EIDs as they appear in EID-Records for all LISP control
>   messages [RFC9301] is the length of the string in bits (including the
>   null 0 octet).
> 
> Is “EID-Prefix length” described here the same as “EID mask-len” described in
> RFC9301?  “EID-Prefix length” is not a string found in FC9301.

I will change it to "EID mask-len". Good find.

> ** Section 3
>   The string of characters are encoded in the ASCII character-set
>   definition [RFC0020].
> 
> To confirm, any RFC20 ASCII string is a valid EID?  For example, “0x01 0x02
> 0x03 0x04” would be valid?  How would a non-terminating 0x00 be handled – is
> that invalid?

Yes, it is valid. There is usually a length field wrapped around the AFI encoding either in the EID mask-len or the LCAF length.

> I concur with the SECDIR reviewer (Rich Salz) that it would be helpful to
> explain this design choice.

We are waiting for direction from the reviewers. They seem to be in conflict of what should be done. We need direction from them.

> ** Section 5.
>   An RLOC that describes an Ingress or Egress
>   Tunnel Router (xTR) behind a NAT device can be identified by its
>   router name, as in [I-D.farinacci-lisp-lispers-net-nat]
> 
> Per [I-D.farinacci-lisp-lispers-net-nat]
> (draft-farinacci-lisp-lispers-net-nat): Given that the IESG conflict review on
> this document came back as “Request not to publish”
> (https://datatracker.ietf.org/doc/conflict-review-farinacci-lisp-lispers-net-nat/)
> is the WG confident that it makes sense to mention this document here?

This is going to be revisited. The document I-D.farinacci-lisp-lispers-net-nat is not a standard or a protocol specification created by the IETF. It is an implementation report.

Dino