Re: ITC copped out on UTC again
The solution is simple - move to TAI. That is the _true_ time, what the master clocks actually keep. UTC is just a variant for creatures living on the surface of the Earth. Being one of those creatures, I voted for keeping leap seconds. UTC seems to fit the global Internet quite nicely, although it has some problems. When we'll inhabit faraway planets and use some other time reference, we'll be facing /more/ problems, not less. The problems caused by leap seconds are that they make it impossible for two machines to know if they are referring to the same point in future time and quite often introduce errors in the present. 1) No machine can determine the number of seconds between two arbitrary UTC dates in the future since there may be a leap second announced. Not true for TAI. TAI is computed after averaging several clocks, so it is not known in advance either. Both UTC and TAI are labels, albeit the latter is smoother. 2) If Machine A is attempting to synchronize with machine B on a future point in time, they cannot do so unless they know that they have the same view of leap seconds. If a leap second is announced and only one makes the correction, an error is introduced. Not true for TAI The problem is still ill-defined for faraway or accelerated machines, according to relativity. For practical purposes, the divergence of their timekeeping is likely, unless they are well connected to a common time reference. In that case, they can as well connect to one another, no? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
On 1/23/12 3:27 AM, Michael Richardson wrote: Eliot == Eliot Lear l...@cisco.com writes: Can you tell me which protocols use future timestamps in an moving form (not stored at rest in a certificate in a DANE RR, for instance), which care about discrepancies of less than 1 minute? Eliot iCal, for one, which can be used for recurring events that Eliot have nothing to do with computers. Also relevant, would be Forgive me for being dense, but I don't understand how this is relevant. You're right, but you asked the wrong, though. To begin with, protocols don't care about anything. It's the people running the applications and services using the protocols that care. We can't say how iCal is being used everywhere. It is entirely possible that someone is using the format for something akin to cron(8). And as to the example you mention, let's look carefully: iCal, as far as I can understand, stores start/end dates in human form. For instance, from RF2445: BEGIN:VTIMEZONE TZID:US-Eastern LAST-MODIFIED:19870101T00Z BEGIN:STANDARD DTSTART:19971026T02 MMDD HHMMSS Note the SS at the end. I'll also note that the TZ database handles leap seconds but can also be used to adjust against UTC in some way. Note I'm not suggesting this, and I'm really glad we have a few years to think about it. Good time to have the dialog, however... Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: primary Paris hotel booking
On 20 Jan 2012, at 00:37, Stuart Cheshire wrote: Good suggestion Brian. I just called our corporate travel department and got the same rate as IETF, including free Internet and breakfast, and cancel by 6 PM on check-in day. Nice if you have such a department :) I booked a room by fax and the email confirmation took 11 days to arrive, so don't expect a quick turnaround. Tim___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
Clint Chaplin clint.chap...@gmail.com wrote: On Fri, Jan 20, 2012 at 10:04 AM, Ofer Inbar c...@a.org wrote: If the main problem with leap seconds is their future unpredictability, isn't there a compromise option between the status quo and no more leap seconds? Couldn't they come up with a fixed schedule for leap seconds for many centuries at a time, based on current predictions of approximately how many will be needed each century? The earth's rate of rotation is not uniform, and the rate of change of that rotation is not uniform, either. So, predicting future rates and rate of change is not possible. Even so, the current state of the art is that leap seconds could be scheduled three years in advance and keep within the |DUT1| 0.9s limit. That would make it easier to cope with leap seconds tables as part of routine software updates, whereas with the current 6 month warning many systems need to treat the data as dynamic, and this in turn causes bootstrap problems. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle, Faeroes: Northwesterly 5 to 7, occasionally gale 8 for a time in north Faeroes, becoming variable 4, then southeasterly 4 or 5 in south later. Rough or very rough. Wintry showers. Good, occasionally poor.___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
Just curious, but I've often used the formulation: day = (now - now % 86400) where now is the output of gmtime() of equivalent to calculate the number of days since the epoch. How is this affected (or not) by the presence of leap seconds, and/or any proposal to remove them. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
Brian E Carpenter brian.e.carpen...@gmail.com wrote: Time is and always will be an arbitrary measurement scheme, and the only thing that makes sense for the Internet is to use the same arbitrary scheme as everybody else. We just have to suck up the resulting inconveniences, as GPS has to. It would be unthinkable to go it alone. Most of the above is correct, but the difficulty with UTC is not arbitrary. There are two important ways of measuring time: either as a precisely uniform series of SI seconds (which has been possible only since the invention of atomic clocks) or as the angle of the earth relative to the sun (the traditional way). The Earth is not a uniform or stable oscillator so we cannot easily predict the exact relation between atomic time and earth time. UTC is a bodge that tries to accommodate these conflicting forms of time in one timescale. Yes, the length of the second and our notations for time and date are arbitrary, but it is not possible to replace them with a new rational arrangement that would make something like UTC less vexing, because there is no standard unit of time that evenly divides the unpredictably variable length of the day. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ North Utsire, South Utsire: Southerly or southeasterly 5 to 7, decreasing 4 at times. Moderate or rough. Wintry showers. Good, occasionally poor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
Ray Bellis ray.bel...@nominet.org.uk wrote: day = (now - now % 86400) where now is the output of gmtime() of equivalent to calculate the number of days since the epoch. How is this affected (or not) by the presence of leap seconds, and/or any proposal to remove them. It is not affected because it is guaranteed to work by POSIX's definition of seconds since the epoch, which ignores leap seconds. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Shannon, South Rockall: Variable 4, becoming cyclonic, then southwesterly, 5 to 7, perhaps gale 8 later in south Rockall. Rough. Occasional rain. Moderate or good. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard ... Please see my comments in https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html which I think have not been addressed. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
On 2012-01-23 18:24, Mike Jones wrote: As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html ... We are going in circles; see https://www.ietf.org/mail-archive/web/oauth/current/msg08118.html. I can only recommend that people who want to know what's going on read the complete mail thread. Also I'd like to point out that I *did* recommend to go to IETF LC despite these issues because I believe that more review from outside the WG is needed here. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
On Mon, Jan 23, 2012 at 4:52 AM, Alessandro Vesely ves...@tana.it wrote: The solution is simple - move to TAI. That is the _true_ time, what the master clocks actually keep. UTC is just a variant for creatures living on the surface of the Earth. Being one of those creatures, I voted for keeping leap seconds. UTC seems to fit the global Internet quite nicely, although it has some problems. When we'll inhabit faraway planets and use some other time reference, we'll be facing /more/ problems, not less. The problems caused by leap seconds are that they make it impossible for two machines to know if they are referring to the same point in future time and quite often introduce errors in the present. 1) No machine can determine the number of seconds between two arbitrary UTC dates in the future since there may be a leap second announced. Not true for TAI. TAI is computed after averaging several clocks, so it is not known in advance either. Both UTC and TAI are labels, albeit the latter is smoother. That is a dodge. While no time system is known perfectly in real time, there are a number of clocks slaved to TAI that can be used to realize TIA in real time to much better than microsecond accuracy (and, of course, that is how we get real time UTC). In any case, the use case being mentioned is about the difference between arbitrary, but specified, epochs, which is independent of the actual errors in the time system being used. 2) If Machine A is attempting to synchronize with machine B on a future point in time, they cannot do so unless they know that they have the same view of leap seconds. If a leap second is announced and only one makes the correction, an error is introduced. Not true for TAI The problem is still ill-defined for faraway or accelerated machines, according to relativity. For practical purposes, the divergence of their timekeeping is likely, unless they are well connected to a common time reference. In that case, they can as well connect to one another, no? It's not ill defined at all, as long as GR and SR are correct. Both make very precise predictions about the difference between measurements made between clocks keeping proper time (i.e., freely running clocks). Einstein synchronization can always be done between such clocks. It is true that a sufficiently distributed set of clocks (say, Earth, Mars and Venus) will not agree on the simultaneity of remote events, but that lack of simultaneity can be exquisitely calculated, and even used for navigation (see, e.g., the Sagnac effect). And, of course, this is also orthogonal to the problem at hand, as UTC, GPS time, TT, all also experience from the same issues, and it has nothing to do with leap seconds. Regards Marshall ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-oauth-v2-23.txt (The OAuth 2.0 Authorization Protocol) to Proposed Standard
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' draft-ietf-oauth-v2-23.txt as a Proposed Standard There are some downrefs in this document that need to be called out in the Last Call notice, which weren't. * There is a normative reference to RFC 1750, which will be updated to point to RFC 4086 before publication. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 4346 (TLS 1.1). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. * There is a normative reference to Informational RFC 2818 (HTTP over TLS). * There is a normative reference to Informational RFC 4627 (application/json Media Type). * There is a normative reference to Informational RFC 4949 (Internet Security Glossary). This is an allowed downref. Barry, document shepherd ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-oauth-v2-23.txt (The OAuth 2.0 Authorization Protocol) to Proposed Standard
On 1/23/12 11:31 AM, Barry Leiba wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' draft-ietf-oauth-v2-23.txt as a Proposed Standard There are some downrefs in this document that need to be called out in the Last Call notice, which weren't. * There is a normative reference to RFC 1750, which will be updated to point to RFC 4086 before publication. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 4346 (TLS 1.1). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. * There is a normative reference to Informational RFC 2818 (HTTP over TLS). * There is a normative reference to Informational RFC 4627 (application/json Media Type). The last two are already in the downref registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Interested in giving a talk at the FCC?
I'd like to whole heartedly endorse this suggestion and encourage a variety of IETF Subject matter experts to give talks relevant to the FCC. I personally help arrange two seminars at the FCC at the invitation of Doug Sicker, Henning's predecessor as CTO The first on was a tutorial on SIP and the second on MPLS. As a rule these kinds of talks should be vendor/policy neutral. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, January 22, 2012 11:10 AM To: ietf@ietf.org Subject: Interested in giving a talk at the FCC? If you're interested in giving a seminar to technical staff and/or economists at the US Federal Communications Commission (FCC), please let me know. The FCC won't be able to pay for travel, so we'd likely schedule any talks when you are in the DC area. Also, if you know of any colleagues the Commission staff should hear from, feel free to suggest them. I won't make any promises that I'll be able to accommodate all or even most offers, but this is an experiment to see if we can broaden the perspectives heard at the FCC. Most FCC staff are generalists, so topics should be accessible and of interest to this community. (In general, the FCC deals with many aspects of wired and wireless communications, and is interested in applications, as well as lower layers. Examples of topics of particular interest are spectrum-related issues, increasing broadband availability, security/privacy, IPv6, PSTN-transition issues, public safety and accessibility. Thus, if you're interested, please get in touch with me with a rough description of what you'd talk about. If there's local interest in your topic, I will get back to you to work out details. There is no deadline as such, so consider this a standing offer. Henning -- Henning Schulzrinne CTO, FCC 7C252, (202) 418-1544 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-xnamercode-00.txt (xNAME RCODE and Status Bits Clarification) to Proposed Standard
At 10:23 23-01-2012, The IESG wrote: The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'xNAME RCODE and Status Bits Clarification' draft-ietf-dnsext-xnamercode-00.txt as a Proposed Standard 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-06. Exceptionally, comments may be From the Introduction Section: This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the (first) xNAME was detected) and subsequent or final query cycles. From Section 2.1: [RFC1035] states that the AA bit is to be set based on whether the server providing the answer with the first owner name in the answer section is authoritative. This specification of the AA bit has not been changed. This specification of the AA bit has not been changed. And Section 2.2: [RFC4035] unambiguously states that the AD bit is to be set in a DNS response header only if the DNSSEC enabled server believes all RRs in the answer and authority sections of that response to be authentic. This specification of the AD bit has not been changed. It is not clear to me what is being clarified about the status bits. In Section 3: The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response. Shouldn't the BE be lowercased? The status of the memo suggests sending comments to namedropp...@ops.ietf.org. Is that IETF mailing list still being used by DNSEXT? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Room sharing in Paris?
Is there an appropriate list/wiki/etc. to discuss possible room sharing arrangements? I'm not going to be able to register for the event until I get this worked out, so I can use the meeting-specific attendees list for that purpose. If there is no such place, I'll state here that I'm interested in discussing sharing a double room for IETF 83 in Paris from March 25th through 31st. Contact me off-line to discuss. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Room sharing in Paris?
Hi Kevin You can register at https://www.ietf.org/meeting/register.html You can hold off on paying until early March. That will give you the ability to edit the meeting wiki: https://www.ietf.org/registration/MeetingWiki/wiki/ietf83 You can easily add a page there for what you're looking for. Alternatively, you can register to the 83attendees list, and ask there. Note, however, that there are currently about 290 people on the list, and there has been no traffic. That's less than a third of the people going to the meeting https://www.ietf.org/mailman/listinfo/83attendees On Jan 23, 2012, at 10:04 PM, Kevin P. Fleming wrote: Is there an appropriate list/wiki/etc. to discuss possible room sharing arrangements? I'm not going to be able to register for the event until I get this worked out, so I can use the meeting-specific attendees list for that purpose. If there is no such place, I'll state here that I'm interested in discussing sharing a double room for IETF 83 in Paris from March 25th through 31st. Contact me off-line to discuss. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Room sharing in Paris?
On 01/23/2012 02:42 PM, Yoav Nir wrote: Hi Kevin You can register at https://www.ietf.org/meeting/register.html You can hold off on paying until early March. Of course, I should have realized that. That will give you the ability to edit the meeting wiki: https://www.ietf.org/registration/MeetingWiki/wiki/ietf83 You can easily add a page there for what you're looking for. I've created the page: https://www.ietf.org/registration/MeetingWiki/wiki/83roomsharing Let's see what happens :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-oauth-v2-23.txt (The OAuth 2.0 Authorization Protocol) to Proposed Standard
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol' draft-ietf-oauth-v2-23.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2012-02-06. 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 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2012-02-06. 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 specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-dhcpv4-bulk-leasequery-05.txt (Bulk DHCPv4 Lease Query) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Bulk DHCPv4 Lease Query' draft-ietf-dhc-dhcpv4-bulk-leasequery-05.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2012-02-06. 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 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-bulk-leasequery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-bulk-leasequery/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-simple-chat-13.txt (Multi-party Chat Using the Message Session Relay Protocol (MSRP)) to Proposed Standard
The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Multi-party Chat Using the Message Session Relay Protocol (MSRP)' draft-ietf-simple-chat-13.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2012-02-06. 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 The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. Note that This document has a downward reference to RFC 4353. Please comment during the last call on the appropriateness of this downref. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dhc-forcerenew-nonce-03.txt (Forcerenew Nonce Authentication) to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Forcerenew Nonce Authentication' draft-ietf-dhc-forcerenew-nonce-03.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2012-02-06. 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 DHCP Forcerenew allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server sends a nonce with the client on the initial DHCP ACK that is used for subsequent validation of a Forcerenew message. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-forcerenew-nonce/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-forcerenew-nonce/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dnsext-xnamercode-00.txt (xNAME RCODE and Status Bits Clarification) to Proposed Standard
The IESG has received a request from the DNS Extensions WG (dnsext) to consider the following document: - 'xNAME RCODE and Status Bits Clarification' draft-ietf-dnsext-xnamercode-00.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2012-02-06. 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 The Domain Name System (DNS) has long provided means, such as CNAME (Canonical Name), where a query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dnsext-xnamercode/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dnsext-xnamercode/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Authentication Failure Reporting using the Abuse Report Format' to Proposed Standard (draft-ietf-marf-authfailure-report-10.txt)
The IESG has approved the following document: - 'Authentication Failure Reporting using the Abuse Report Format' (draft-ietf-marf-authfailure-report-10.txt) as a Proposed Standard This document is the product of the Messaging Abuse Reporting Format Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report/ Technical Summary This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure. Working Group Summary This memo underwent two Working Group Last Calls because of the amount of last-minute feedback generated during the first. There was no controversy of note. Document Quality There is substantial deployment of ARF, upon which these extensions are based. There is one widely deployed open source implementation of the extension with more under development which will see widespread use. Reviewers and expressions of intent to support included PayPal and Hotmail. Personnel Murray S. Kucherawy m...@cloudmark.com is the Document Shepherd Pete Resnick presn...@qualcomm.com is the Responsible Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'OSPFv2 Multi-Instance Extensions' to Proposed Standard (draft-ietf-ospf-multi-instance-09.txt)
The IESG has approved the following document: - 'OSPFv2 Multi-Instance Extensions' (draft-ietf-ospf-multi-instance-09.txt) as a Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ospf-multi-instance/ Technical Summary This draft extends OSPFv2 to support multiple routing domains on the same subnet - a capability that already exists in OSPFv3. This is different from OSPFv3 where it could be used for other purposes such as putting the same interface in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. Working Group Summary The only discussion worth noting was the behavior of legacy routers receiving OSPF packets with non-Zero instance ID. It was concluded that the such packets would be misinterpreted as having mismatched authentication type and would get dropped. Such errors should get logged and should result in the generation of SNMP traps. There was concern that this could be an issue if every packet would result in SNMP trap generation. However, it was discussed that this will not be an issue since most implementations will damp the logging of errors and generation of identical SNMP traps. Document Quality There is one known implementation. Personnel Manav Bhatia is the Document Shepherd. Stewart Bryant is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Moving A6 to Historic Status' to Informational RFC (draft-jiang-a6-to-historic-00.txt)
The IESG has approved the following document: - 'Moving A6 to Historic Status' (draft-jiang-a6-to-historic-00.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-jiang-a6-to-historic/ Technical Summary This document provides a summary of issues and discusses the current usage status of A6 DNS records and moves the A6 specifications to Historic status, providing clarity to implementers and operators. Working Group Summary No major issues raised. Document was discussed on the DNSEXT list, but the chairs considered that the WG already had too many other unfinished items so this document is being processed as AD-sponsored. Document Quality The document itself is clear. The whole point is that the feature is not deployed and is not considered useful. Personnel Ralph Droms rdroms.i...@gmail.com is the Sponsoring and Responsible AD. RFC Editor Note Please make the following editorial changes prior to publication: Change the Abstract: OLD: This document provides a summary of issues and discusses the current usage status of A6 DNS records and moves the A6 specifications to Historic status, providing clarity to implementers and operators. NEW: This document provides a summary of issues and discusses the current usage status of A6 DNS records and moves the RFC 2874 to Historic status, providing clarity to implementers and operators. Change the last paragraph of Section 1: OLD: deployment, this document moves the A6 specifications to Historic status, thereby clarifying that implementers and operators should represent IPv6 addresses in the DNS only by using records. NEW: deployment, this document moves RFC 2874 [RFC2874] to Historic status, thereby clarifying that implementers and operators should represent IPv6 addresses in the DNS only by using records. Change Section 6: OLD: IANA is requested to change the annotation of the A6 RR type from Experimental to Obsolete in the DNS Parameters registry. NEW: IANA is requested to change the annotation of the A6 RR type (code 38) from Experimental to Obsolete in the DNS Parameters registry. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DNS Extensions to Support IPv6 Address Aggregation and Renumbering' (RFC 2874) to Historic
The IESG has approved the following document: - 'DNS Extensions to Support IPv6 Address Aggregation and Renumbering ' RFC 2874 as a Historic RFC This document is the product of the IP Version 6 Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this RFC is: https://datatracker.ietf.org/doc/rfc2874/ Technical Summary This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type (called A6) to store an IPv6 address in a manner that expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing. A6 records can hold all or part of an address, with pointers to other DNS names holding the remaining part of the address. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure that allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. Working Group Summary This document was discussed extensively in both the IPNG and DNSIND working groups. Although concern has been raised that use of the A6 records will increase the demands placed on the DNS when resolving names to addresses, the goal of easing site renumbering was deemed important and the mechanism described in this document was viewed as the best approach. Protocol Quality This document has been reviewed for the IESG by Thomas Narten and Erik Nordmark. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
