I support adoption of this draft...
On Thu, Sep 05, 2024 at 2:32 PM, Jen Linkova <furr...@gmail.com> wrote: > I support adoption. > > This draft is very useful for cases beyond ones mentioned in the draft. In > particular, we are going to abandon > draft-equinox-intarea-icmpext-xlat-source and suggest that CLAT utilizes > the extension defined in > draft-fenner-intarea-extended-icmp-hostid. > So I'd really like this draft to advance (so draft-ietf-v6ops-claton can > refer to this draft as well). > … and I'd really like this draft to advance so that draft-chroboczek-intarea-v4-via-v6 - "IPv4 routes with an IPv6 next hop" <https://datatracker.ietf.org/doc/draft-chroboczek-intarea-v4-via-v6/> can refer to it… :-) W > A few comments (Bill, Reji - pls let me know if you prefer Github PR > instead or in addition to my comments below): > > 1) Maybe it's worth mentioning the CLAT case in the introduction? > 2) 3.2. Node IP Address Sub-Object > "Address: This variable-length field represents an address of appropriate > scope (global, if none other defined) that can be used to identify the > node." > > First of all, if the field is *variable-length*, then the length shall be > indicated somewhere. However I suspect that the field can be either 32 bits > or 128 bits long (at least until we start working on IPv7 ;) So I'd suggest > making it more explicit and say that if AFI = 1 then that field is 32 bits, > and if AFI= 2 then it's 128 bits. > > 3) For the Node Name Sub-Object it would be useful to specify the parsing > behaviour: if the length > 64, the receiver MUST ignore the object. > > 4) Security Considerations: > - "MUST default to off" would be a problem for CLAT, don't you think? ;) > The same applies to "The intended field of use for the extensions defined > in this document is administrative debugging and troubleshooting. The > extensions herein defined supply additional information in ICMP responses. > These mechanisms are not intended to be used in non-debugging > applications." > Maybe we can call IPv6 -> Ipv4 translation explicitly and allow it to be > used by default? > > On Thu, Sep 5, 2024 at 8:37 PM Wassim Haddad > <wassim.haddad=40ericsson....@dmarc.ietf.org> wrote: > > Dear IntArea WG, > > This note triggers a 2-week call for adoption of “Extending ICMP for Node > Identification” draft: > > https://datatracker.ietf.org/doc/ > draft-fenner-intarea-extended-icmp-hostid/ > > If you have an opinion on whether this document should be adopted by the > IntArea WG please indicate it on the mailing list by the end of Friday, > September 20th. > > Thanks, > > Wassim & Juan-Carlos > > (IntArea WG chairs) > > _______________________________________________ > Int-area mailing list -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org > > -- > Cheers, Jen Linkova > > _______________________________________________ > Int-area mailing list -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
