RE: Ietf Digest, Vol 10, Issue 76
of interest or feasibility - Remote Telco - Electric power distribution. We are still soliciting help in gathering requirements information for - Uses of precise time in networking - Metrology If anyone can help in these latter applications, please contact the TICTOC chairs. If no interest is expressed, we intend removing these applications from the list of applications being considered. In addition, if someone feels we missed an application that requires distribution of timing information, it is possibly not too late to consider its inclusion. Thanks Y(J)S -- next part -- An HTML attachment was scrubbed... URL: http://www.ietf.org/mail-archive/web/ietf/attachments/20090325/286fb03a/attachment.htm -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf End of Ietf Digest, Vol 10, Issue 76 _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-peterson-rai-rfc3427bis (Change Process forthe Session Initiation Protocol (SIP)) to Proposed Standard]
I'd like to echo Alan's point here... 4. In the security considerations of most SIP extensions, we inevitably end up referring to S/MIME. However, we know that there is no S/MIME deployments with SIP, essentially making the resulting security considerations irrelevant. Perhaps some guidance on practical security considerations would be worthwhile going forward, given the heavy reliance on hop-by-hop security and transitive trust in deployed SIP systems. We've got to quit pointing to S/MIME when we know that no one believes us! The input I'm getting from SIPconnect/1.1 contributors is that they're not even excited about hop-by-hop TLS - a fair number of deployments are running wide open. I'm thinking this isn't going to end well. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
On 23-Mar-2009, at 14:35, Melinda Shore wrote: I was auto-subscribed to Dean's ietf-honest mailing list, and I'm unhappy about it. As I think was mentioned a day or two ago on this list, the reasonable way I found to avoid these auto-subscriptions to ietf-honest was to block packets from the originating network. I had a very enjoyable few days following the installation of those packet filters. However, it now seems that (a) any address I've used in the past is now fair game, and not just the addresses I'm using today, and (b) it's not just the ietf list, but working group lists too, e.g. see below. I don't have the same ability to do server-side filtering or packet blocking on other mail accounts. I have lost my sense of humour about this. It's hard to see this as anything other than a systematic attempt to disrupt IETF activities. I am generally capable of taking care of my own mail abuse problems, but I'm annoyed that I have to, and I'm annoyed that the pool of volunteer hours available to the IETF to get work done is being deliberately eroded by someone whose current and past behaviour, to me, seems to have little intent other than to waste peoples' time. If there's a way for the IETF leadership, or the IETF secretariat, or some other centralised body to take some initiative here and reduce the disruption for the benefit of all those trying to get work done, I at least would appreciate it. Joe Begin forwarded message: From: dnsop-honest-requ...@lists.iadl.org Date: 25 March 2009 09:43:27 PDT To: jabley@(redacted) Subject: Welcome to the Dnsop-honest mailing list Welcome to the dnsop-hon...@lists.iadl.org mailing list! This mailing list is for IETF DNSOP WG members to discuss IETF business without improper censorship. It does not represent the IETF but does represent some IETF members. This list was created by IADL.ORG (www.iadl.org) because of dishonest filtering by the IESG. See http://www.av8.net/IETF-watch for more information on the corrupt activities of officials of the Internet Society, Inc (ISOC) IETF Activity, and their connection to other corrupt activities. You were probably added to this list because you participated in dn...@ietf.org discussion, and that list is used to determine consensus for ISOC IETF Activity actions. Consensus is a democratic activity of the ISOC, which is a U.S. non-profit, tax exempt membership corporation. ALL members of the ISOC IETF have a property right to participate in its democratic decision processes. [see U.S. v. Local 560, extortion (Hobbs Act) and racketeering by mafia that took over a Union and tried to prevent participation by those opposing the mafia] Email sent to this list will be forwarded to dn...@ietf.org. Ordinary IETF members should feel free to unsubscribe from this list if they choose. IETF representatives (e.g. Working Group Chairs) have a duty to the corporation to read email sent to them on IETF business, and should not try to unsubscribe. To post to this list, send your email to: dnsop-hon...@lists.iadl.org General information about the mailing list is at: http://lists.iadl.org/mailman/listinfo/dnsop-honest If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.iadl.org/mailman/options/dnsop-honest/jabley%40ca.afilias.info You can also make such adjustments via email by sending a message to: dnsop-honest-requ...@lists.iadl.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: ovbadeig Normally, Mailman will remind you of your lists.iadl.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Welcome to the Dnsop-honest mailing list
And now it's happening for the dnsop list... On Wed, Mar 25, 2009 at 12:43:27PM -0400, dnsop-honest-requ...@lists.iadl.org wrote: Welcome to the dnsop-hon...@lists.iadl.org mailing list! This mailing list is for IETF DNSOP WG members to discuss IETF business without improper censorship. It does not represent the IETF but does represent some IETF members. This list was created by IADL.ORG (www.iadl.org) because of dishonest filtering by the IESG. See http://www.av8.net/IETF-watch for more information on the corrupt activities of officials of the Internet Society, Inc (ISOC) IETF Activity, and their connection to other corrupt activities. You were probably added to this list because you participated in dn...@ietf.org discussion, and that list is used to determine consensus for ISOC IETF Activity actions. Consensus is a democratic activity of the ISOC, which is a U.S. non-profit, tax exempt membership corporation. ALL members of the ISOC IETF have a property right to participate in its democratic decision processes. [see U.S. v. Local 560, extortion (Hobbs Act) and racketeering by mafia that took over a Union and tried to prevent participation by those opposing the mafia] Email sent to this list will be forwarded to dn...@ietf.org. Ordinary IETF members should feel free to unsubscribe from this list if they choose. IETF representatives (e.g. Working Group Chairs) have a duty to the corporation to read email sent to them on IETF business, and should not try to unsubscribe. To post to this list, send your email to: dnsop-hon...@lists.iadl.org General information about the mailing list is at: http://lists.iadl.org/mailman/listinfo/dnsop-honest If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.iadl.org/mailman/options/dnsop-honest/tjc%40ecs.soton.ac.uk You can also make such adjustments via email by sending a message to: dnsop-honest-requ...@lists.iadl.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: Normally, Mailman will remind you of your lists.iadl.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
Joe Abley wrote: On 23-Mar-2009, at 14:35, Melinda Shore wrote: I was auto-subscribed to Dean's ietf-honest mailing list, and I'm unhappy about it. As I think was mentioned a day or two ago on this list, the reasonable way I found to avoid these auto-subscriptions to ietf-honest was to block packets from the originating network. I had a very enjoyable few days following the installation of those packet filters. However, it now seems that (a) any address I've used in the past is now fair game, and not just the addresses I'm using today, and (b) it's not just the ietf list, but working group lists too, e.g. see below. I don't have the same ability to do server-side filtering or packet blocking on other mail accounts. Seems he wants the core of the Internet to apply those filters... I must say that I love the wording: This list was created by IADL.ORG (www.iadl.org) because of dishonest filtering by the IESG. See http://www.av8.net/IETF-watch for more information on the corrupt activities of officials of the Internet Society, Inc (ISOC) IETF Activity, and their connection to other corrupt activities. Those are clear allegations of corruption. Isn't that what the IETF calls an ad-hominum attack? Wasn't there something about that about causing subscriptions to be able to be blocked etc? You were probably added to this list because you participated in dn...@ietf.org discussion, and that list is used to determine consensus for ISOC IETF Activity actions. Consensus is a democratic activity of the ISOC, which is a U.S. non-profit, tax exempt membership corporation. ALL members of the ISOC IETF have a property right to participate in its democratic decision processes. [see U.S. v. Local 560, extortion (Hobbs Act) and racketeering by mafia that took over a Union and tried to prevent participation by those opposing the mafia] Nice one, the IETF is compared to the Mafia. [..] IETF representatives (e.g. Working Group Chairs) have a duty to the corporation to read email sent to them on IETF business, and should not try to unsubscribe. And here it goes: as a WG chair you are not able to unsubscribe, you are not even allowed to try. Nice Mafia-alike practice. I didn't know that the IETF was incorporated btw. All news to me ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
On Wed, Mar 25, 2009 at 10:10:04AM -0700, Joe Abley wrote: I have lost my sense of humour about this. It's hard to see this as anything other than a systematic attempt to disrupt IETF activities. It is my suspicion that the perpetrating gang is attempting to goad volunteers into legal recourse. I suspect this gang believes that their actions will either cause IETF volunteers to create a legal context for them to exploit (CAN SPAM suits), or that IETF's attempts to filter or restrict access will create a legal context for them to attack (the gang's leadership cites Exactis vs MAPS with fervor, which I think they believe proves a network cannot restrict access to itself). Heads we win, tails you lose. Anyone who's ever participated in an Internet community knows the score here. There are trolls for whom ostracization from the community solves the problem; they find another community to infect and become distracted. There are trolls that never believed they were part of the community to start with, bold adventurers or risk takers, individualists outside the realm of conformity, lone rangers who must stand alone against a tide of injustice. Ostracization does not quiet their discomfort, it justifies it. The only thing I have seen work for this second category of troll is to talk to their mother. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpABhYUNxp2E.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repair of Public Mail List Archives Complete
Randy, Suresh Thanks for the info. I do like my Web interface to a mailing list once I am in approximately the right time frame and I know of no such interface to an IETF list archive any more. By contrast, the IRTF archives, such as ICCRG and TMRG are excellent. The nearest such IETF facility is CCAMP but that has less function and uses https:-( with a certificate that my browser rejects. Tom Petch - Original Message - From: Randy Presuhn randy_pres...@mindspring.com To: ietf@ietf.org Sent: Tuesday, March 17, 2009 8:15 PM Subject: Re: Repair of Public Mail List Archives Complete Hi - From: Tom.Petch sisyp...@dial.pipex.com To: Alexa Morris amor...@amsl.com Cc: ietf@ietf.org Sent: Tuesday, March 17, 2009 2:34 AM Subject: Re: Repair of Public Mail List Archives Complete ... But when I really need an archive, to see what was agreed in 2006, I have to get there day by day by painstaking day by tedious day at a time. I can see no other more direct way. The files at ftp://ftp.ietf.org/ietf-mail-archive/ are much better suited for such searches, especially when the time frame is fuzzy. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF74 plenary stream URL
We seem to be missing the link off of the tools page. The URL for the plenary is http://feed.verilan.com:8000/continental_5.m3u. If you have the main playlist for this meeting, you can use the stream for Continental 5. Morgan Sackett VP of Engineering VeriLAN Event Services, Inc. 215 SE Morrison Street Portland, OR 97214 Tel: 503 907-1415 Fax: 503 224-8833 msack...@verilan.com www.verilan.com This e-mail contains proprietary information and may be confidential. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you received this message in error, please delete it immediately. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 plenary stream URL
On 2009-03-25 15:50 Morgan Sackett said the following: We seem to be missing the link off of the tools page. The URL for the plenary is http://feed.verilan.com:8000/continental_5.m3u. If you have the main playlist for this meeting, you can use the stream for Continental 5. Fixed. Also fixed a link bug where the link to the plenary materials for Wednesday and Thursday were swapped. Best, Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Subscription information for ietf-nomcom
Samuel and Jim have graciously reminded me that it might be good to post the mailing list information for ietf-nomcom. The list information is at http://www.ietf.org/mailman/listinfo/ietf-nomcom. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Routing Backus-Naur Form (RBNF) : A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications' to Proposed Standard
The IESG has approved the following document: - 'Routing Backus-Naur Form (RBNF) : A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications ' draft-farrel-rtg-common-bnf-09.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-09.txt Technical Summary Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. This document provides a formal definition of the variant of BNF that has been used (that we call Reduced BNF), and makes it available for use by new protocols. Working Group Summary This is an individual submission with AD sponsorship. It was presented to the routing area open meeting. A couple of people questioned whether this was needed at all, but no one objected to the content. The IETF last call was flagged to the CCAMP, MPLS, PCE and TSVWG WGs, and to the routing-discussion email list. Document Quality Multiple existing routing area specifications use the subset of BNF defined in this document. Personnel Ross Callon is the sponsoring AD. Adrian Farrel is the author, and has been shepherding this document through the various reviews. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'NETCONF Over Transport Layer Security (TLS)' to Proposed Standard
The IESG has approved the following document: - 'NETCONF Over Transport Layer Security (TLS) ' draft-ietf-netconf-tls-07.txt as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-07.txt Technical Summary The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to provide a secure connection for the transport of NETCONF messages. The mechanisms defined in this document include the support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication and key management capabilities of the TLS (Transport Layer Security) protocol. Working Group Summary Many WG member were thinking that password-based authentication is already handled well enough by the existing NETCONF transports (SSH and BEEP), and the NETCONF-over- TLS specification does not need to handle passwords. It has been recommended to scope the document to certificate- based authentication. There was also some controversy on the use of pre-shared keys (PSKs) derived from passwords. Based on this dicussion the Working Group decided to remove the text related to PSK based- authentication. See http://www.ietf.org/mail-archive/web/netconf/current/msg03856.html There was some controversal discussion about the Connection Closure. The consensus was that the document adopts the closure mechanism from draft-ietf-syslog-transport-tls-, Section 4.4. There was also some controversy about the use of a dedicated port of NETCONF over TLS. The consensus was that a dedicated port should be requested. The summary of the last changes can be found in: http://www.ietf.org/mail-archive/web/netconf/current/msg03873.html http://www.ietf.org/mail-archive/web/netconf/current/msg03882.html There were many WG members who did not strongly support or object to the document. Nobody objected to the document during or after the WGLC. The level of review in the WG was adequate , with several independent reviews by WG members. There is WG consensus to publish the document. Document Quality No vendors have announced that they will utilize this protocol. Two implementations with independent code-base and initiated by the document author are available as open source. The author ensures that the two implementations have been tested as interoperable. Personnel The document was reviewed by Eric Rescorla, Juergen Schoenwaelder, David Harrington, the WG security advisor Charlie Kaufman, and the security ADs Pasi Eronen and Tim Polk. Mehmet Ersue is the document shepherd, and Dan Romascanu the shepherding AD. RFC Editor Note Please make the following changes to draft-07: 1. In Section 2.1: OLD: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. NEW: Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. The server MUST support certificate-based client authentication. 2. In Section 3.2 OLD: The server may have no external knowledge on client's identity and identity checks might not be possible (unless the client has a certificate chain rooted in an appropriate CA). If a server has knowledge on client's identity (typically from some source external to NETCONF or TLS) it MUST check the identity as described above. NEW: The server MUST verify the identity of the client with certificate-based authentication and according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. 3. In Section 4: OLD: This document in its current version does not support third party authentication due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. NEW: This document in its current version does not support third party authentication (e.g., backend AAA servers) due to the fact that TLS does not specify this way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third party authentication is needed, BEEP or SSH transport can be used. 4. Please create an Informative References section and move RFC4642 and RFC5277 from the Normative References section to this new section. ___ IETF-Announce
Protocol Action: 'Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming' to Proposed Standard
The IESG has approved the following document: - 'Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming ' draft-ietf-shim6-failure-detection-13.txt as a Proposed Standard This document is the product of the Site Multihoming by IPv6 Intermediation Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-13.txt Technical Summary This document specifies how the level 3 multihoming shim protocol (SHIM6) detects failures between two communicating hosts that are using this protocol. It also specifies an exploration protocol for identifying a viable pair of interfaces and/or addresses between SHIM6 hosts. Working Group Summary The document has extensively reviewed by the Working Group. The Working Group consensus was to recommend publication of this document as a Proposed Standard. Document Quality There are known implementations of this specification, and there have been no implemtation experiences that have implied any further revision to this specification is required. Note to RFC Editor Please update reference to draft-ietf-dna-protocol to the latest draft version. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)' to Proposed Standard
The IESG has approved the following document:
- 'Encoding of Objective Functions in the Path Computation Element
Communication Protocol (PCEP) '
draft-ietf-pce-of-06.txt as a Proposed Standard
This document is the product of the Path Computation Element Working
Group.
The IESG contact persons are Ross Callon and David Ward.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-of-06.txt
Technical Summary
The computation of one or a set of Traffic Engineering Label
Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) networks, is subject to a set of one
or more specific optimization criteria, referred to as objective
functions (e.g. minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a Path
Computation Client (PCC) may want a path to be computed for one or
more TE LSPs according to a specific objective function. Thus, the
PCC needs the ability to instruct the PCE to use the correct
objective function. Furthermore, it is possible that not all PCEs
support the same set of objective functions, therefore it is useful
for the PCC to be able to automatically discover the set of objective
functions supported by each PCE.
This document defines extensions to the PCE communication Protocol
(PCEP) to allow a PCE to indicate the set of objective functions it
supports. Extensions are also defined so that a PCC can indicate in
a path computation request the required objective function, and so
that a PCE can report in a path computation reply the objective
function that was used for path computation.
Working Group Summary
No controversy reported (see PROTO writeup by Adrian Farrel). The
I-D had a good level of review and discussion when it was first
introduced. However, the last year has been quiet and the working
group last call produced no comments. To be sure that there was
support, the working group was asked to provide explicit review
and approval. A number of participants responded supporting
publication.
Document Quality
A private survey has revealed several implementations of the
PCEP extensions defined in this document. Furthermore, there
are several further extensions in the pipeline that make use
of these extensions to enable new applications of PCE. The
document was updated in response to IETF last call comments.
Personnel
Adrian Farrel is the Document Shepherd for this document. Ross
Callon is the Responsible Area Director.
RFC Editor Note
Section 4., paragraph 7:
OLD
Objective Function Code: 2 (suggested value, to be assigned by IANA)
Name: Minimum Load Path (MLP)
Description: Find a path P such that
( Max {(R(Lpi) - r(Lpi) / R(Lpi), i=1...K } ) is minimized.
NEW
Objective Function Code: 2 (suggested value, to be assigned by IANA)
Name: Minimum Load Path (MLP)
Description: Find a path P such that
( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.
Section 6.1
OLD
- Function code values 1 through 1023 are to be assigned by IANA
using the IETF Consensus policy.
NEW
- Function code values 1 through 1023 are to be assigned by IANA
using the IETF Review policy.
Section 6.1
OLD
Six objective functions are defined in Section 4 of this document
and should be assigned by IANA:
Code Point NameDefining RFC
NEW
Six objective functions are defined in Section 4 of this document
and should be assigned by IANA:
Code Point NameReference
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
