Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-09-02 Thread Phillip Hallam-Baker
On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt schl...@theworld.com wrote: As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier

Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-09-02 Thread John Levine
The engineering solution to this deployment problem is to generalize the problem and use a new record for that. Either that or figure out how to make it easy enough to deploy new RRTYPEs that people are willing to do so. The type number is 16 bits, after all. We're not in any danger of running

Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-09-02 Thread David Conrad
John, Either that or figure out how to make it easy enough to deploy new RRTYPEs that people are willing to do so. The type number is 16 bits, after all. We're not in any danger of running out. We have been told on numerous occasions that one of the primary reasons for continued use of

Re: PS Characterization Clarified

2013-09-02 Thread Jari Arkko
Olaf, Scott, Apologies for a late reply on this (I was on vacation after the IETF). But thank you for writing this draft. My general comment is that the draft makes what in my mind is an accurate correction to our documents, aligning the documents to the current reality. I'd be happy to take

Re: making our meetings more worth the time/expense

2013-09-02 Thread Stewart Bryant
On 31/07/2013 15:00, Barry Leiba wrote: The most valuable part of IETF meeting is and has always been the hall conversations and side meetings I think *side meetings* are killing IETF, I call it *hidden meetings*, there is no input for IETF when we have side meetings. The input to IETF in

Re: Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-09-02 Thread Phillip Hallam-Baker
On Mon, Sep 2, 2013 at 9:56 AM, David Conrad d...@virtualized.org wrote: John, Either that or figure out how to make it easy enough to deploy new RRTYPEs that people are willing to do so. The type number is 16 bits, after all. We're not in any danger of running out. We have been

Re: PS Characterization Clarified

2013-09-02 Thread Scott O Bradner
On Sep 2, 2013, at 10:23 AM, Jari Arkko jari.ar...@piuha.net wrote: Olaf, Scott, Apologies for a late reply on this (I was on vacation after the IETF). But thank you for writing this draft. My general comment is that the draft makes what in my mind is an accurate correction to our

Creating an umbrella group for Network Sync Protocols

2013-09-02 Thread todd
Folks the value of network based time sync efforts has been long understood in this community but ... I want to propose now that it (time and network sync) be elevated within the IETF even farther so that time itself becomes the vertical allowing the IETF to bundle all of the legacy and new

Re: PS Characterization Clarified

2013-09-02 Thread Brian E Carpenter
Hi Jari, On 03/09/2013 02:23, Jari Arkko wrote: ... At the time of this writing, the IETF operates as if the Proposed Standard was the last chance for the to ensure the quality of the technology and the clarity of the standards document. There's a point that I think should be made here,

Re: PS Characterization Clarified

2013-09-02 Thread John C Klensin
--On Monday, 02 September, 2013 14:09 -0400 Scott O Bradner s...@sobco.com wrote: There is at least one ongoing effort right now that has the potential to reclassify a large set of Proposed Standard RFCs that form the basis of widely used technology. These types of efforts can have a

Re: PS Characterization Clarified

2013-09-02 Thread Jari Arkko
There's a point that I think should be made here, something like: In practice, interoperable implementations are commonly based on Proposed Standard documents, so whatever design defects those documents have tend to become part of the interoperable network, perhaps in the form of