I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
Please resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-repute-media-type-10
Reviewer:
SM:
I certainly agree that in incidents like this, a timely notification is in
order. (Of course to the extent that the outage itself allows us to do that.
Sometimes the outage or the queue that has built up during the outage delays
sending a notification.)
And we normally do send
I will also add that when I requested it Steve sent me a list that
indicated who sent what messages to the mailing lists that I moderate. That
was really helpful as I could ping folks to resend and I was able to resend
those that I had sent myself, so it wasn't too onerous to recover given
that we
Hi.
Inspired by part of the SPF discussion but separate from it,
Patrik, Andrew, and I discovered a shortage of registries for
assorted DNS RDATA elements. We have posted a draft to
establish one for TXT RDATA. If this requires significant
discussion, we seek guidance from relevant ADs as to
On Fri, Aug 30, 2013 at 9:35 AM, John C Klensin john-i...@jck.com wrote:
Hi.
Inspired by part of the SPF discussion but separate from it,
Patrik, Andrew, and I discovered a shortage of registries for
assorted DNS RDATA elements. We have posted a draft to
establish one for TXT RDATA. If
Hi Jari,
At 01:05 30-08-2013, Jari Arkko wrote:
I certainly agree that in incidents like this, a timely notification
is in order. (Of course to the extent that the outage itself allows
us to do that. Sometimes the outage or the queue that has built up
during the outage delays sending a
Hi Phillip,
--On August 30, 2013 at 10:16:46 AM -0400 Phillip Hallam-Baker
hal...@gmail.com wrote:
Service discovery requires prefixes.
Here is a draft that works fine (except for the IETF review mistake). Just
put IETF last call on it:
This is helpful feedback.
We are looking at how the listing of the registries is used by the
community.
There have been suggestions of adding keywords to help when people search
for registries.
As the list of registries grows, we want to make sure it is useful and
that registries can easily be
--On Friday, August 30, 2013 11:48 -0400 Phillip Hallam-Baker
hal...@gmail.com wrote:
I believe that draft was superseded by RFC6335 and all
service names (SRV prefix labels) are now recorded at
http://www.iana.org/**
assignments/service-names-**port-numbers/service-names-**
I did not participate in the original working group that developed SPF.
However I had a number of long phone conversations with one of the folks
who was active in the group. A good part of those conversations involved
the use of the TXT record. I objected to overloading that RR. In
response
I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
Please resolve these comments along with any other Last Call comments you may
receive. Please
On Fri, Aug 30, 2013 at 10:38 AM, Cyrus Daboo cy...@daboo.name wrote:
Hi Phillip,
--On August 30, 2013 at 10:16:46 AM -0400 Phillip Hallam-Baker
hal...@gmail.com wrote:
Service discovery requires prefixes.
Here is a draft that works fine (except for the IETF review mistake). Just
put
CR LF was first adopted for the Telnet NVT (Network Virtual Terminal). I
think it was Jon
Postel's choice, and no one disagreed. Then when FTP was defined, it
seemed most economical
to use the same. In fact, doesn't the FTP spec explicitly say that the
conventions on the control
connection
John,
I don't think it would of been fun designing and testing a text-based
hosting protocol manually with your terminal/telecommunication/telnet
client New Line Mode (add LF to CR) option disabled or server text
responses only issue CR or LF.
It would of been very hard or confusing to do
On Fri, Aug 30, 2013 at 12:20 PM, Andrew Sullivan
a...@anvilwalrusden.comwrote:
On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
For example, DKIM-REPUTE product designers would need to consider
SPF reputons product models. Simple text as follows can resolve the
integration
On 30 aug 2013, at 21:35, John C Klensin john-i...@jck.com wrote:
The more prefixes versus more RRTYPES versus subtypes versus
pushing some of these ideas into a different CLASS versus
whatever else one can think of are also very interesting... and
have nothing to do with whether this
On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
For example, DKIM-REPUTE product designers would need to consider
SPF reputons product models. Simple text as follows can resolve the
integration consideration with little SPF fanfare the draft
obviously tried to avoid:
Why
Hi. I'm going to comment very sparsely on responses to this
draft, especially those that slide off into issues that seem
basically irrelevant to the registry and the motivation for its
creation. My primary reason is that I don't want to burden the
IETF list with a back-and-forth exchange,
On 31/08/2013 02:26, SM wrote:
...
The nit is why is the IETF still using PDT.
I assure you that things were operationally much worse when the
Secretariat was using EDT.
Really - the service level has improved continuously over the last
eight years. Of course things can always be better, and
On 8/30/2013 10:46 AM, Tony Hansen wrote:
The document describes a model for reputation services, particularly those
being produced by the Repute WG. It follows the recommendations of RFc4101 for
describing a protocol model, which requires answers to 1) the problem the
protocol is trying to
Hi Andrew,
I think it can be generalized functional description without
specifics. Designs based on REPUTE and its users of such products,
will need some information. That may come (hopefully) from the REPUTE
product designer. I am suggesting to remind such future REPUTE product
designers of
On Aug 30, 2013, at 5:26 PM, SM s...@resistor.net wrote:
The nit is why is the IETF still using PDT.
Because we don't want to get into a religious war of GMT vs UTC.
On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:
archives of the Repute WG to find or extract these very real and
practical integration considerations. The document should have
these general considerations summarized.
But your suggestion was for protocol-specific advice. I
--On Friday, August 30, 2013 09:56 -0700 Bob Braden
bra...@isi.edu wrote:
CR LF was first adopted for the Telnet NVT (Network Virtual
Terminal). I think it was Jon
Postel's choice, and no one disagreed.
A tad more complicated, IIR. It turns out that, with some
systems interpreting LF as
On 8/30/2013 4:09 PM, Andrew Sullivan wrote:
On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:
archives of the Repute WG to find or extract these very real and
practical integration considerations. The document should have
these general considerations summarized.
But your
On 8/30/2013 2:37 PM, Hector Santos wrote:
On 8/30/2013 10:46 AM, Tony Hansen wrote:
The document describes a model for reputation services, particularly
those being produced by the Repute WG. It follows the recommendations
of RFc4101 for describing a protocol model, which requires answers to
Dear Tony,
Use of DKIM offers a very poor authentication example, since this draft makes
the same errors made in RFC5863. It is wrong to suggest the DKIM protocol
permits associating a validated identifier to a message as stated in the
Introduction. This is the same erroneous conflation of a
Hi Doug!
On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote:
Use of DKIM offers a very poor authentication example
Thanks for the feedback. I don't recall you having made this point on
the repute mailing list. Did you, I missed it?
Do you have a better example, specifically
Hello,
After reading the reviews of the Application Area Directorate review
it seems to me that there is some misunderstanding of what an
Application Area Directorate review is about. The review is to give
the Applications Area Directors a sense of how important it is that
they pay
Hello,
At 09:53 30-08-2013, The IESG wrote:
The Dynamic Host Configuration (dhc) working group in the Internet Area
of the IETF is undergoing rechartering. The IESG has not made any
[snip]
Milestones:
Done - WG Last Call on DHCP Options for Internet Storage Name
Service
Colleagues, and Doug especially,
The message I sent (below) wasn't intended as a shut up and go away
message, but a genuine query. I have grave doubts that TLS is the
right example (to begin with, I think fitting it into the REPUTE
approach, given the existing CA structure, would also be
On Aug 30, 2013, at 9:17 PM, S Moonesamy sm+i...@elandsys.com wrote:
Did the DHC working group read the milestones? I ask because it's been a few
years since the year 2008 ended.
Yes. The minutes have been updated in the datatracker:
https://datatracker.ietf.org/wg/dhc/charter/
I don't
Hi Ted,
At 19:59 30-08-2013, Ted Lemon wrote:
Yes. The minutes have been updated in the datatracker:
https://datatracker.ietf.org/wg/dhc/charter/
Thanks.
I don't know why this didn't show up in the announcement
message. Actually, the
I assumed that the message was generated by the
On Fri, Aug 30, 2013 at 09:10:25PM -0700, S Moonesamy wrote:
At 19:59 30-08-2013, Ted Lemon wrote:
announcement really ought to just point to the datatracker, since
what's there is normative.
This is an individual opinion. Please assume that the entire IETF
disagrees with it. The
The Dynamic Host Configuration (dhc) working group in the Internet Area
of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing
The IESG has approved the following document:
- 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
802 Parameters'
(draft-eastlake-rfc5342bis-05.txt) as Best Current Practice
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
36 matches
Mail list logo
