[Ietf-dkim] Erik Kline's No Objection on charter-ietf-dkim-04-03: (with COMMENT)

2022-12-29 Thread Erik Kline via Datatracker
Erik Kline has entered the following ballot position for charter-ietf-dkim-04-03: 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.) The document, along

Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

2013-08-22 Thread Erik Kline
REQ 1: 6434 5.9.1 is already a MUST. This does not need to be repeated. 6434 5.8 is already a MUST. Unless you want to make multipart ICMP a MUST (why?) as well, this too can be removed. REQ 6: re 6434 12.2, this MUST does not appear to be stronger than 12.2's MUST frankly even

Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC

2012-02-06 Thread Erik Kline
On 4 February 2012 01:35, Fred Baker f...@cisco.com wrote: On Feb 2, 2012, at 6:57 PM, Erik Kline wrote: World IPv6 Launch changes the relevance of this document greatly, I think.  Since this would be published after the announcement of World IPv6 Launch, I think the document should

Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC

2012-02-03 Thread Erik Kline
World IPv6 Launch changes the relevance of this document greatly, I think. Since this would be published after the announcement of World IPv6 Launch, I think the document should be updated to discuss its own applicability in a post- World IPv6 Launch Internet. On 2 February 2012 00:09, The IESG

Re: [v6ops] 6to4v2 (as in ripv2)?

2011-07-27 Thread Erik Kline
Moving 6to4 to historic does not in any way impact your ability to use it as you wish. 6to4 support is not part of the IPv6 node requirements, as I understand it. Therefore I believe that any vendor (OS, router, otherwise) could deleted 6to4 support in any release and be in violation of

Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)

2011-07-19 Thread Erik Kline
Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? I don't see any progress. We may just have to blacklist any resolvers that have 6to4 clients behind them and leave it at that.

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

2011-07-05 Thread Erik Kline
All, Perhaps declaring 6to4 deprecated rather than historic would have a better chance of consensus. Pardon my ignorance, but where is the document describing the implications of historic{,al} vs deprecated? This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known: A

Re: [v6ops] draft-ietf-v6ops-6to4-to-historic

2011-07-05 Thread Erik Kline
Perhaps declaring 6to4 deprecated rather than historic would have a better chance of consensus. Pardon my ignorance, but where is the document describing the implications of historic{,al} vs deprecated? This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known:    A

Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

2011-06-15 Thread Erik Kline
The youtube folks made the decision to leave the video-serving hostnames available in blacklist-mode, meaning only very broken networks won't get s. This is being watched, and could easily change back. The exact policy for blacklisting has yet to be fully formalized. But re: 6to4 in this

Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

2011-05-03 Thread Erik Kline
I'm having a hard time thinking of adequate alternatives terms (but this purely a personal failing, I'm sure). Recommendations for other words? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf