Erik Kline has entered the following ballot position for draft-ietf-netmod-rfc6991-bis-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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Internet AD comments for draft-ietf-netmod-rfc6991-bis-17 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments * "typedef protocol-number { If IPv6 extension headers are present, then the protocol number type represents the upper layer protocol number, i.e., the number of the last 'next header' field of the IPv6 extension headers." Surely since this can represent all values of the Next Header field this _could_ indicate the value of an IPv6 Extension Header? It seems to me that we should just say this is the value of the protocol/next header field wherever this numberspace is indicated, and that in some contexts extension headers might be skipped over and the ultimate next header value is what is meant in this field. This should be called out on a case-by-case basis, though, I would expect (i.e. wherever this type is used). * ipv[46]-address-no-zone Why are these patterns so much more permissive than the non-zone parts of the address patterns? Why not just copy the address pattern text and leave off the %<zone> pattern chunk? * email-address This pattern seems overly permissive. It appears to permit the RFC 5322 S3.2.3 "specials" that are not part of "dot-atom". I'm no SMTP expert, but it seems like at least excluding the @ special might help? E.g. [^@]+@[^@]+ or something. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
