Hi Magnus, thanks for your comments. Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft is expired, so making it normative might not be an option.
Since it is meant to replace RFC3819, should we refer to RFC3819 instead? Thanks, Fabio On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" <[email protected]> wrote: Magnus Westerlund has entered the following ballot position for draft-ietf-lisp-gpe-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4.2: To me it looks like this is normative reference: Such new encapsulated payloads, when registered with LISP- GPE, MUST be accompanied by a set of guidelines derived from [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. Section 4.3.1: Thanks for writing relevant guidance on how to mitigate the risks with zero checksum. Especially the one on traffic separation from other traffic so that it can be caught on the boundaries of the network to prevent the risk to other networks from corrupted traffic. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
