[Ietf-dkim] Erik Kline's No Objection on charter-ietf-dkim-04-03: (with COMMENT)
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 with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dkim/
--
COMMENT:
--
# Internet AD comments for {doc-rev}
CC @ekline
## Nits
* The ends of both paragraphs one and two appear to define problematic
email content, in nearly the same terms. Perhaps de-dup?
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
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
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 5.2 reads like MUST for 3GPP, but it does SHOULD so this MUST appears stronger. Bizarre, though, I never noticed that ND SHOULD before. REQ 10: this reads kind weird. In REQ 9 you require 6106 support, but in REQ 10 you say if 6106 is not supported. I think you mean something like if the network to which the mobile node is attaching does not support 6016.
Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
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 be updated to discuss its own applicability in a post- World IPv6 Launch Internet. With respect... The document was originally discussed in v6ops, and you chose to not comment. It went through last call there in January 2011 and was sent to the IESG. IESG review took until April, and an updated draft was posted at the end of May 2011. At IETF 81 (Quebec City) we were able to have you, the author, and some others discuss it. The IESG again decided it needed a revised draft, and that draft - in large part, a rewrite - arrived in October. v6ops had a second WGLC, in which you again declined to comment, although you may have seen Lorenzo's comments, which were picked up in a November version of the draft. Ralph and Jari finally cleared their discuss ballots a couple of weeks ago, and we are having a second IETF last call. I'd like to understand your objective here. I know that you don't care for the draft, and at least at one point took it as a somewhat-personal attack. Is your objective to prevent the draft's publication entirely, or do you think that there is value in publishing it given a productive response to this comment? At what point are you willing to either participate in the public dialog or choose to not comment at all? With humblest apologies... Having spent time rereading, I think W6L is clearly an implementation of sections 4.5 and 5.7, or 4.4 and 5.6, depending on the implementer. Additionally, in retrospect, there's probably no great reason to add a reference to a future event. It seems to me that the most meaningful technical observation that can actually be offered would be its scheduled calendar date. There's no excuse for my failing to reread afresh before commenting. Again, my apologies, -Erik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
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 iesg-secret...@ietf.org wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Considerations for Transitioning Content to IPv6' draft-ietf-v6ops-v6--whitelisting-implications-08.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6--whitelisting-implications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6--whitelisting-implications/ No IPR declarations have been submitted directly on this I-D. ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
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 anything, regardless of historic status. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
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 specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
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 specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the Historic level. (Purists have suggested that the
word should be Historical; however, at this point the use of
Historic is historical.)
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
I don't know where similar explanatory language about Deprecated
might be (I'm sure I just didn't search correctly or long enough).
Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being
declared historic also mean that 6rd needs to become historic as well?
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Section 1, in which the draft clarifies that 6rd supersedes 6to4,
which meets the qualification in the first paragraph of the Historic
term. With 6rd we clearly don't need to have anything built on top of
6to4 in the future, addressing the 2nd paragraph.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
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 case, it still gains you nothing you didn't already have while risking randomly crappy performance. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
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
