With respect to the question of proposed standard. What changes if the
requested status is informational?
I think just get rid of the normative language - SHOULDs, MUSTs, etc.
that is orthogonal to info/ps
next unnecessary rathole, please
randy
joe,
i spent time actually reading the document and commenting on it, one was
a substantive comment, at least to me.
any chance you could pull yourself away from the exemplary
anti-productive nitpicking maelstrom for a few minutes and respond?
thanks.
randy
--On Tuesday, May 21, 2013 11:07 +0200 Stephane Bortzmeyer
bortzme...@nic.fr wrote:
...
Although these tests certainly contributed to the good
technical quality of the name servers, they were removed both
for commercial reasons (a registry has to make money to pay
its employees) and because
On May 22, 2013, at 3:10 PM, John C Klensin john-i...@jck.com wrote:
--On Tuesday, May 21, 2013 11:07 +0200 Stephane Bortzmeyer
bortzme...@nic.fr wrote:
...
Although these tests certainly contributed to the good
technical quality of the name servers, they were removed both
for
Hi Randy,
On 2013-05-21, at 11:23, Randy Bush ra...@psg.com wrote:
i have read the draft. if published, i would prefer it as a proposed
standard as it does specify protocol data objects.
Noted, thanks.
It does seem that the main objection to the standards track for this document
is that I
Back when I worked at a service provider, we helped customers with their DNS
configurations, Sendmail, usenet news (yes, it was a long time ago), and other
services. If they were new customers, we would help them with the setup or if
something was broken we would look at the configuration,
--On Wednesday, May 22, 2013 12:29 + Yoav Nir
y...@checkpoint.com wrote:
Occasional fantasies about IETF enforcement power and the
Protocol Police notwithstanding, it seems to me that, if one
wanted to require standards-conforming nameservers, the most
(and maybe only) effective way to
At 05:56 22-05-2013, Moriarty, Kathleen wrote:
providers. While tying this to contracts seems like a good idea,
that is out of our hands at the IETF. If we went down the path of
enforcement through contracts, I wouldn't view this as picking
fights, but rather a proactive service to 'help'
In message 6.2.5.6.2.20130522123025.0b3ef...@resistor.net, SM writes:
At 05:56 22-05-2013, Moriarty, Kathleen wrote:
providers. While tying this to contracts seems like a good idea,
that is out of our hands at the IETF. If we went down the path of
enforcement through contracts, I wouldn't
From: John C Klensin john-i...@jck.com
My problem here, which I hope was clear from
the note from which you quoted, is that a request/document in
the second category was proposed for Standards Track and then
that comments that would be entirely appropriate for a Last Call
on a Standards
From: Keith Moore mo...@network-heretics.com
On 05/21/2013 10:04 AM, Joe Abley wrote:
With respect, *my* question as the author of this document is
simply whether the specification provided is unambiguous and
sufficient. It was my understanding that this was the question
before the
On Wed, May 22, 2013 at 10:03 PM, Dale R. Worley wor...@ariadne.com wrote:
...
Coming into this from the outside, the issues are interesting.
I originally thought RRTYPEs are scarce, since all the ones I was
aware of are less than 256. But it turns out that RRTYPEs are 16 bit
integers, and
In message 9506594e9e3cb989afbc0...@jck-hp8200.jck.com, John C Klensin writes:
--On Wednesday, May 22, 2013 12:29 + Yoav Nir
y...@checkpoint.com wrote:
Occasional fantasies about IETF enforcement power and the
Protocol Police notwithstanding, it seems to me that, if one
wanted
A new Request for Comments is now available in online RFC libraries.
RFC 6932
Title: Brainpool Elliptic Curves for the
Internet Key Exchange (IKE) Group Description
Registry
Author: D. Harkins, Ed.
A new Request for Comments is now available in online RFC libraries.
RFC 6953
Title: Protocol to Access White-Space (PAWS)
Databases: Use Cases and Requirements
Author: A. Mancuso, Ed.,
S. Probasco, B. Patil
The Javascript Object Signing and Encryption (jose) working group in the
Security Area of the IETF has been rechartered. For additional
information please contact the Area Directors or the WG Chairs.
Javascript Object Signing and Encryption (jose)
The IESG has received a request from the Light-Weight Implementation
Guidance WG (lwig) to consider the following document:
- 'Terminology for Constrained Node Networks'
draft-ietf-lwig-terminology-04.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and
17 matches
Mail list logo
