Alvaro Retana has entered the following ballot position for draft-ietf-softwire-mesh-multicast-23: 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-softwire-mesh-multicast/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format". Even though source address mapping had just been discussed (§5.3), it wasn't clear right away that you were talking about the same thing. Maybe it was the name used ("IPv4-Embedded IPv6 Virtual Source Address Format"), which doesn't show up anywhere else. Putting a note in §5.3 about the name would be nice. (2) §5.4: "...every AFBR MUST announce the address of one of its E-IPv4 interfaces in the "v4" field..." Please put a reference here to rfc6052 (so it's easy to remember where that field came from). (3) §6.4: "According to [RFC7761], it SHOULD propagate..." That SHOULD is out of place because it is not normative in this document. Either change it to 'should', or quote the text. (4) §6.4: Several SHOULDs are used in this section. In general, are there cases where it's ok to not follow the specification? For example, "When RP' receives this encapsulated message, it SHOULD decapsulate..." -- are there cases where the RP' wouldn't decapsulate. IOW, why not use MUST instead? (5) §6.4: "...so RP' SHOULD NOT simply process this message as specified in [RFC7761] on the incoming interface." That "SHOULD NOT" seems to just be a statement and not have normative value (the normative text comes in the next paragraph). s/SHOULD NOT/should not _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
