Re: [lisp] Suggested UDP checksum text

I think the wordsmithing on the UDP checksum got tangled up.
Whenever you get to making a revision, assuming that the WG stays with 
the intent of what you have written (which seems like a good choice to 
me), I would suggest:

UDP Checksum: this field MAY be set to 0 by an ITR on transmission.
     Alternatively, an ITR MAY compute and store a valid UDP checksum
     in this field during transmission.   Upon receipt, and ETR MUST
     accept a value of 0 as valid for this field, and consider the UDP
     packet valid.  If an ETR receives a non-zero value  in the
     checksum, field it MAY compute and validate the UDP checksum for
     the packet.  If it chooses to do so, it is expected to discard
     UDP packets with invalid non-zero checksums.
Then include the note text you already have.

Does that make sense?  Saying "When an ITR transmits...an ETR may 
compute is confusing.  It is particularly confusing since the note 
indicates that the ETR can not tell whether the ITR or someone else 
filled in the checksum field with a non-zero value.

Yours,
Joel

Dino Farinacci wrote:
> Just a friendly reminder that the proposed changes to 
> draft-ietf-lisp-04.txt is this Friday September 4th.
> 
> Thank you to all who have sent us comments last week. For those of you 
> who have not reviewed the diffs yet, you can look at the updated html 
> diff file enclosed.
> 
> The change-log of the proposed changes is also enclosed. Please note 
> there are 6 additional change-log entries at the end reflecting comments 
> we received last week.
> 
> Thanks a lot,
> Dino/Dave/Darrel/Vince
> 
> ------------------------------------------------------------------------------- 
> 
> 
> Changes planned for draft-ietf-lisp-04.txt:
> 
> * How do deal with record count greater than 1 for a Map-Request. Damien 
> and
>   Joel comment. Joel suggests:
> 
>     1) Specify that senders compliant with the current document will
>     always set the count to 1, and note that the count is included for
>     future extensibility.
> 
>     2) Specify what a receiver compliant with the draft should do if it
>     receives a request with a count greater than 1. Presumably, it should
>     send some error back?
> 
> * Add Fred Templin in ack section.
> 
> * Add Margaret and Sam to the ack section for their great comments.
> 
> * Say more about LAGs in the UDP section per Sam Hartman's comment.
> 
> * Sam wants to use MAY instead of SHOULD for ignoring checkums on ETR. From
>   the mailing list:
> 
>   You'd need to word it as an ITR MAY send a zero checksum, an ETR MUST
>   accept a 0 checksum and MAY ignore the checksum completely.  And of
>   course we'd need to confirm that can actually be implemented.  In
>   particular, hardware that verifies UDP checksums on receive needs to
>   be checked to make sure it permits 0 checksums.
> 
> * Margaret wants a reference to http://www.ietf.org/id/draft-eubanks-
>   chimento-6man-00.txt.
> 
> * Fix description in Map-Request section. Where we describe Map-Reply 
> Record,
>   change "R-bit" to "M-bit".
> 
> * Add the mobility bit to Map-Replies. So PTRs don't probe so often for MNs
>   but often enough to get mapping updates.
> 
> * Indicate SHA1 can be used as well for Map-Registers.
> 
> * More Fred comments on MTU handling.
> 
> * Isidor comment about specing better periodic Map-Registers. Will be fixed
>   in draft-ietf-lisp-ms-02.txt.
> 
> * Margaret's comment on gleaning:
> 
>     The current specification does not make it clear how long gleaned map
>     entries should be retained in the cache, nor does it make it clear
>     how/ when they will be validated.  The LISP spec should, at the very
>     least,  include a (short) default lifetime for gleaned entries,
>     require that  they be validated within a short period of time, and
>     state that a new  gleaned entry should never overwrite an entry that
>     was obtained from  the mapping system.   The security implications of
>     storing "gleaned"  entries should also be explored in detail.
> 
> * Add section on RLOC-probing per working group feedback.
> 
> * Change "loc-reach-bits" to "loc-status-bits" per comment from Noel.
> 
> * Remove SMR-bit from data-plane. Dino prefers to have it in the control
>   plane only.
> 
> * Change LISP header to allow a "Research Bit" so the Nonce and LSB fields
>   can be turned off and used for another future purpose. For Luigi et al
>   versioning convergence.
> 
> * Add a N-bit to the data header suggested by Noel. Then the nonce field 
> could
>   be used when N is not 1.
> 
> * Clarify that when E-bit is 0, the nonce field can be an echoed nonce or
>   a random nonce. Comment from Jesper.
> 
> * Indicate when doing data-gleaning that a verifying Map-Request is sent
>   to the source-EID of the gleaned data packet so we can avoid map-cache
>   corruption by a 3rd party. Comment from Pedro.
> 
> * Indicate that a verifying Map-Request, for accepting mapping data, 
> should be
>   sent over the the ALT (or to the EID).
> 
> * Reference IPsec RFC 4302. Comment from Sam and Brian Weis.
> 
> * Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-noncing.
>   Comment by Pedro and Dino.
> 
> * Jesper made a comment to loosen the language about requiring the copy of
>   inner TTL to outer TTL since the text to get mixed-AF traceroute to 
> work would
>   violate the "MUST" clause. Changed from MUST to SHOULD in section 5.3.
> 
> ------------------------------------------------------------------------------- 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp