From my side, yes. Thanks a lot for your quick responses on this! Cheers, Brian > On 30 Aug 2018, at 18:09, Dino Farinacci <farinacci@xxxxxxxxx> wrote: > > Thanks for the great discussion Brian. I think we’re all in sync now? > > Dino > >> On Aug 30, 2018, at 8:46 AM, Brian Trammell (IETF) <ietf@xxxxxxxxxxx> wrote: >> >> >> >>> On 30 Aug 2018, at 16:55, Dino Farinacci <farinacci@xxxxxxxxx> wrote: >>> >>>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) <ietf@xxxxxxxxxxx> wrote: >>>> >>>> hi Dino, >>>> >>>> Almost. How about: >>>> >>>> >>>> OLD: >>>> >>>> When the UDP and LISP headers require integrity protection, the >>>> methods of using UDP checksums in [RFC8085] can be considered. >>>> >>>> NEW: >>>> >>>> Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer IPv6 headers require protection against corruption, the use of non-zero UDP checksums is RECOMMENDED. >>> >>> Well if we recommend it and when describing the UDP header in the packet format section we don’t that woudl be a contracdiction. >> >> I think my point here is that the packet format section probably shouldn't do that. :) Yes, I understand the disconnect between the reality of the situation and the >> >>> And note the IPv6 outer header cannot be protected with a UDP checksum. The link-layer CRC will do that. >> >> Eh, this makes assumptions about the underlying link layer's corruption characteristics that may not hold. But yeah, for most packets in most realistic situations this is the case, and I guess we've learned to live with the underlying phy error rate * 1e-10 in any case. >> >>> NEWNEW: >>> >>> Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when >>> it is desirable to protect UDP and LISP headers against corruption. >>> >>> What do you think? >> >> This seems like a fine compromise to me. >> >> Thanks, cheers, >> >> Brian >> >>> >>> Dino >>> >>> _______________________________________________ >>> Tsv-art mailing list >>> Tsv-art@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/tsv-art >> >
Attachment:
signature.asc
Description: Message signed with OpenPGP