> 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 _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
