On 10/10/2013 19:50, The IESG wrote:
The IESG has received a request to update the IANA registration of
the text/csv media type, adding an optional fragment identifier.
The request comes from a document in the Independent stream, and the
IESG is the change controller for the text/csv media type.
On 17/09/2013 11:32, Dave Cridland wrote:
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl
mailto:o...@nlnetlabs.nl wrote:
Based on the conversation below I converged to:
t
While less mature specifications will usually be published as
On 02/08/2013 08:23, The IESG wrote:
The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Out-of-Band Public Key Validation for Transport Layer Security (TLS)'
draft-ietf-tls-oob-pubkey-09.txt as Proposed Standard
The IESG plans to
On 26/06/2013 16:18, Pete Resnick wrote:
On 4/1/13 4:41 PM, Robert Sparks wrote:
On 3/28/13 1:17 PM, SM wrote:
At 05:13 28-03-2013, Burger Eric wrote:
I use the IMAP interface once, mark a bunch of things as read, and
then decide never to use the IMAP interface ever again. How long
does the
On 12/06/2013 15:16, ned+i...@mauve.mrochek.com wrote:
Dave Cridland wrote:
I strongly feel that positive statements have value, as they allow the
community to gauge the level of review and consensus, and I suspect that
human nature means that we get more reviews if people get to brag about it.
Hi Eric,
I am sorry if I sound pedantic below, but I think your suggestion can be
misinterpreted and thus needs improving:
On 28/03/2013 12:13, Burger Eric wrote:
Rather than guessing all of the bad things that could happen, I would offer it
would be better to say what we mean, like:
On 27 Mar 2013, at 20:31, Robert Sparks rjspa...@nostrum.com wrote:
While looking at it, I noticed we don't explicitly say that this IMAP
interface MUST NOT
allow messages in the archive to be deleted
I would actually allow administrative users to delete messages (e.g. spam), but
such
On 15 Mar 2013, at 13:35, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'The TLS Multiple Certificate Status Request Extension'
draft-ietf-tls-multiple-cert-status-extension-04.txt as
On 14/03/2013 13:41, John C Klensin wrote:
--On Thursday, 14 March, 2013 07:41 -0500 Mary Barnes
mary.ietf.bar...@gmail.com wrote:
[MB] It would be interesting to know then how many newcomers
check in on Sunday versus Monday morning. Maybe we could move
the Meet 'n Greet til later in the week
On 02/08/2012 10:46, Ben Campbell wrote:
Hi, thanks for the response. Comments inline:
On Jul 29, 2012, at 10:29 PM, =JeffH jeff.hod...@kingsmountain.com wrote:
[...]
-- section 7.2:
Am I correct to assume that the server must never just serve the content over
a non-secure connection? If
Hi Simon,
On 10/07/2012 18:50, Simon Perreault wrote:
On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
I found the justification for REQ-6 hard to read/understand. Why does
access to
servers being on the internal network need to go through CGN at all?
Here's the thing: the server
Hi SM,
Thank you for the comments.
On 06/06/2012 22:39, SM wrote:
At 13:05 04-06-2012, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Tunneling of SMTP Message Transfer Priorities'
Reviewer: Alexey Melnikov
Review Date: 3-July-2012
IETF LC End Date: 10-July-2012
IESG Telechat date: Pending
Summary: The document is ready for publication as a BCP.
Major Issues: None
Minor Issues: None
Nits/editorial comments:
I found it is to be odd to have a requirements document as a BCP
Hi Paul,
On 14 Jun 2012, at 05:02, Paul Sangster paul_sangs...@symantec.com wrote:
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Monday, June 04, 2012 12:02 PM
To: apps-disc...@ietf.org; draft-ietf-nea-pt-tls@tools.ietf.org
Cc: ietf@ietf.org
Hi Paul,
On 14/06/2012 05:11, Paul Sangster wrote:
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Wednesday, June 13, 2012 3:47 AM
To: apps-disc...@ietf.org; draft-ietf-nea-pt-tls@tools.ietf.org
Cc: ietf@ietf.org
Subject: Re: [apps-discuss] APPSDIR
On 04/06/2012 20:01, Alexey Melnikov wrote:
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
Adding to what SM already wrote (and yes, I've reread the whole document):
On 1 Jun 2012, at 21:23, SM s...@resistor.net wrote:
At 09:42 01-06-2012, IESG Secretary wrote:
The IESG has received a request from the TLS Working Group to reclassify RFC
2818 (HTTP Over TLS) to Proposed Standard.
wait for direction from your document shepherd
or AD before posting a new version of the draft. The review is not
copied to the IESG as the Last Call has not been announced yet.
Document: draft-ietf-nea-pt-tls-04
Title: PT-TLS: A TCP-based Posture Transport (PT) Protocol
Reviewer: Alexey
Hi Roni,
On 20/05/2012 07:47, Roni Even wrote:
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
Hi Roni,
Thank you for your review.
On 13/03/2012 19:25, Roni Even wrote:
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
On 05/03/2012 19:40, Barry Leiba wrote:
2. I, too, noticed all the lower-case should and may words. I
suggest that the best way to handle this is to make the following
change to the RFC 2119 citation text at the beginning of section 2:
NEW
The key words MUST, MUST NOT, REQUIRED, SHALL,
On 05/03/2012 18:00, Murray S. Kucherawy wrote:
-Original Message-
From: Alexey Melnikov [mailto:alexey.melni...@isode.com]
Sent: Monday, March 05, 2012 4:00 AM
To: Murray S. Kucherawy
Cc:ietf@ietf.org
Subject: Re: Last Call:draft-melnikov-smtp-priority-07.txt (Simple
Mail Transfer
Hi Ned,
On 05/03/2012 15:34, Ned Freed wrote:
That said, I think an important omission in this document is that it
only allows MSA's to change message priorities to conform to site
policy.
MTAs should also be allowed to do this.
Can you elaborate a bit more on possible use cases?
On 01/03/2012 20:49, Barry Leiba wrote:
I had expected that we'd deal with my shepherd review before doing the
last call on the document. Because that didn't happen, I'll re-post
my review here, as public last-call comments. Maybe that will prevent
people from raising the same things I've
Hi Murray,
Thank you for the comments. Some answers below.
On 01/03/2012 04:43, Murray S. Kucherawy wrote:
I have several comments on this draft. But first, this is a big improvement
since the last version I reviewed, so kudos to the authors.
A couple of these refer to issues in the document
Hi Ned,
On 02/03/2012 06:12, Ned Freed wrote:
The most significant item that needs to be called out is the issue of
tunneling the PRIORITY value through non-conforming MTAs by turning it
into a message header field (MT-Priority) and then back again. This
is a problematic technique, but is an
On 03/03/2012 18:07, ned+i...@mauve.mrochek.com wrote:
[...]
So I have two suggestions. One is to leave it as is, and make it
experimental. If it turns out the tunnels all work the same way, you
can come back and add the spec about how they work and rev it as
standards track. The other is to
On 31/01/2012 10:33, Alexey Melnikov wrote:
On 30/01/2012 05:20, Mike Jones wrote:
[...]
About your third minor issue on RFC 6125 versus RFC 2818, you'll find
that, per the history entries, a previous reference to RFC 2818 was
changed to RFC 6125 in draft 14 at the request of Security Area
,
-- Mike
-Original Message-
From:ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alexey
Melnikov
Sent: Sunday, January 29, 2012 8:38 AM
To: General Area Review Team; IETF-Discussion
Discussion;draft-ietf-oauth-v2-bearer@tools.ietf.org
Subject
Reviewer: Alexey Melnikov
Review Date: 29 Jan 2012
IETF LC End Date: 7 Feb 2012
IESG Telechat date: (if known) -
Summary: Mostly ready, with a couple of things that should be addressed.
Major Issues:
I have 2 issues in section 3:
3. The WWW-Authenticate Response Header Field
If the protected
On 27/01/2012 01:50, Barry Leiba wrote:
[...]
On Thu, Jan 26, 2012 at 12:37 PM, John C Klensin john-i...@jck.com
wrote: We were told by the other company employees who facilitated
the disclosures, at the time of the disclosures, that this was strictly an individual's failure to comply with
On 08/12/2011 18:12, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Item and Collection Link Relations'
draft-amundsen-item-and-collection-link-relations-04.txt as an
Informational RFC
The IESG plans to make a decision
On 01/12/2011 16:21, The IESG wrote:
The IESG has received a request from the Messaging Abuse Reporting Format
WG (marf) to consider the following document:
- 'Redaction of Potentially Sensitive Data from Mail Abuse Reports'
draft-ietf-marf-redaction-03.txt as an Informational RFC
The IESG
On 28/11/2011 23:42, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'URI Template'
draft-gregorio-uritemplate-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
Emil Ivov wrote:
Hey Alexey,
Hi Emil,
On 27 sept. 2011, at 00:24, Alexey Melnikov alexey.melni...@isode.com
mailto:alexey.melni...@isode.com wrote:
Jonathan Lennox wrote:
Hi, Alexey -- thank you for the Gen-ART review.
Hi Jonathan,
Alexey Melnikov writes:
Question: are the two
Jonathan Lennox wrote:
Hi, Alexey -- thank you for the Gen-ART review.
Hi Jonathan,
Alexey Melnikov writes:
Question: are the two encoding of the audio level indication option specified
in the document really necessary?
Do you mean the one-byte vs. two-byte forms of the header
-avtext-client-to-mixer-audio-level-05.txt
Reviewer: Alexey Melnikov
Review Date: 2011-09-25
IETF LC End Date: 2011-10-04
IESG Telechat date:
Summary: The document is ready for publication as a standards track RFC.
Major issues: none
Minor issues:
Question: are the two encoding of the audio level
Hi Mykyta,
Thank you for the review. My answers are below.
Mykyta Yevstifeyev wrote:
So some small comments:
1) A nit in Change controller field for all the header fields: you
should either change it to IESG (i...@ietf.org) or IETF with
subsequent address ietf@ietf.org.
I don't think this
t.petch wrote:
I notice that section 3, to which IANA are directed, contains many formulations
such as
Specification document(s): [[anchor14: this document]]
Would I be right in thinking that this is what other documents would refer to as
RFC
-- Note to RFC-Editor - replace RFC by
Mykyta Yevstifeyev wrote:
15.09.2011 11:59, Alexey Melnikov wrote:
t.petch wrote:
I notice that section 3, to which IANA are directed, contains many
formulations
such as
Specification document(s): [[anchor14: this document]]
Would I be right in thinking that this is what other
-reason-responses-05
Reviewer: Alexey Melnikov
Review Date:2011-08-20
IETF LC End Date: 2011-09-08
IESG Telechat date:
Summary: This draft is ready for publication as a standard track RFC.
Major issues: none
Minor issues: none
Nits/editorial comments: none
Murray S. Kucherawy wrote:
+1, which is to say:
- I've read it
- I agree with what it says
- I can't find any reason not to move it to Full Standard
- Nice job all around
Well said, so +1 for all of the above.
One pedantic nit:
8.4. Transfer Encode
The MSA MAY apply transfer encoding
Dave Cridland wrote:
On Thu Jul 21 18:18:31 2011, David Endicott wrote:
It is my opinion that name resolution (however done) is outside the
purview
of WS. It may be handled in any number of ways by the client, and must
happen *before* WS establishes it's TCP connection and begins
Hi Richard,
Thanks for the review. I will answer to some of your comments and I or
my co-editor will followup on remaining issues later on.
Richard L. Barnes wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
Vint Cerf wrote:
setting aside interpretation and semantics for a moment, would there
be utility in maintaining tables for each instance of Unicode?
Yes, because developers will have different versions of Unicode
available to them. It would also help developers to migrate by seeing
what has
Paul Hoffman wrote:
On Jun 7, 2011, at 6:24 PM, John C Klensin wrote:
I think this is an improvement but there is one issue about
which we have slightly different impressions. I hope the
difference can be resolved without needing yet more tedious
arguments about documentation. Indeed, if
Pete Resnick wrote:
[...]
Section 2.2
(a) Specifically, merge Draft Standard into Internet Standard
(b) Combine criteria from Draft Standard and Standard
(i) Significant number of implementations with successful
operational experience
(ii) No unresolved errata causing interoperational
John C Klensin wrote:
Sean,
Seems fine to me but, like Sam, I'd prefer to not clutter
abstracts For a specification RFC that is rendered Historic by
a new specification, the combination of an Obsoletes header
and a note in the Introduction ought to be sufficient.
I don't mind having a note
Hi Stewart,
Stewart Bryant wrote:
The IESG is considering making this statement on the
processing of RFC Errata concerning RFC Metadata.
We would appreciate community feedback.
Please can we have feedback by Thursday 9th June.
Thanks
Stewart
==
Draft text for IESG Statement on RFC
Mykyta Yevstifeyev wrote:
Hello,
The proposed statement is mostly fine. But, since RFC 2026 gives very
little information on some issues, I'd like you considered them in the
statement.
First, for RFCs of what categories is it legitimate to move them to
Historic. Whether Experimental or
Hi Julian,
Julian Reschke wrote:
On 09.05.2011 16:34, Russ Housley wrote:
...
My person experience with advancing documents is that downrefs are a
significant hindrance. As you point out, procedures have been
adopted to permit downrefs, but they are not sufficient. We often
see Last
Hi Ben,
Thanks for your review.
Ben Campbell wrote:
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
Peter Saint-Andre wrote:
On 4/19/11 1:47 PM, Paul Lambert wrote:
How does the area that the group is assigned impact the choices of
technology?
I'm an advocate for an efficient solution set for PAWS ... it will be
much like DNS for spectrum in the future and should be viewed as a
core
Alexey Melnikov wrote:
Peter Saint-Andre wrote:
Agreed, thanks to Paul for the proposed text.
On 2/15/11 9:02 PM, Cullen Jennings wrote:
Paul's text is much better than mine. That was what I trying to get
at.
Agreed, I will add this as an RFC Editor's note.
On Feb 15, 2011, at 8:59 PM
Peter Saint-Andre wrote:
Agreed, thanks to Paul for the proposed text.
On 2/15/11 9:02 PM, Cullen Jennings wrote:
Paul's text is much better than mine. That was what I trying to get
at.
Agreed, I will add this as an RFC Editor's note.
On Feb 15, 2011, at 8:59 PM, Paul Hoffman
Hi Paul (and Cullen),
Paul Hoffman wrote:
On 1/29/11 9:34 PM, Joe Touch wrote:
On 1/29/2011 8:54 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
...
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the
Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request
for an IETF-approved protocol that needs two ports without recourse.
I don't follow. Assignments through IETF-stream
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- ''Headers-Not-Recognized' HTTP Header Field'
draft-yevstifeyev-http-headers-not-recognized-08.txt as an
Experimental RFC
The IESG plans to make a decision in the next few weeks,
Hi John/SM,
As I am partially responsible for the final RFC Editor note that was
inserted before the document got approved, I feel obligated to comment
on this.
John C Klensin wrote:
--On Wednesday, September 15, 2010 13:59 -0700 SM
s...@resistor.net wrote:
Hello,
At 09:37 08-08-10,
Hi SM,
SM wrote:
[...]
Although there was strong concerns about this draft during the
Last-Call, the IESG has approved publication. Quoting some comments
made recently by an Area Director:
I don't think that it specifies well requirements it is trying to
fulfil and it doesn't use email
SM wrote:
At 08:51 18-06-10, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Use of SRV records for locating CalDAV and CardDAV services '
draft-daboo-srv-caldav-05.txt as a Proposed Standard
The IESG plans to make a
Sam Hartman wrote:
Jiankang == Jiankang YAO ya...@cnnic.cn writes:
Jiankang If there are many things we must do, we(WGs) normally
Jiankang prioritize the things. sometimes, the easier one first;
Jiankang sometimes, the difficult one first.
Sure.
That's fine for the WG to
Hi Mark,
Mark Lentczner wrote:
On May 19, 2010, at 6:40 AM, Peter Saint-Andre wrote:
[...]
In an email exchange with Marc and Alexey Melnikov last week, I proposed
adding ...
Although the group will seek input from and may provide advice to
customers working on other technologies
Barry Leiba wrote:
--On Monday, 12 April, 2010 12:44 -0700 The IESG
iesg-secret...@ietf.org wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'File Transfer Protocol HOST Command '
draft-hethmon-mcmurray-ftp-hosts-11.txt as a
Hi Bernie,
Bernie Hoeneisen wrote:
I am a bit puzzeled that according to
https://datatracker.ietf.org/idtracker/draft-gould-rfc4310bis/
draft-gould-rfc4310bis has already been placed on the IESG Telechat
agenda, before the IETF Last Call has even ended.
Did this happen intentionally or
Alexey Melnikov wrote:
Hi Bernie,
Bernie Hoeneisen wrote:
[...]
Please be informed that on the provreg mailing list
http://www.cafax.se/ietf-provreg/maillist/2010-01/maillist.html
there is a heavy discussion going on about the shortcomings of the
current proposal. At least two issues
Nicolas Williams wrote:
On Thu, Dec 03, 2009 at 07:02:53PM +, Alexey Melnikov wrote:
Hi Nico,
Nicolas Williams wrote:
13.3. Additional Recommendations
If the application requires security layers then it MUST prefer the
SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS
Hi Nico,
Nicolas Williams wrote:
13.3. Additional Recommendations
If the application requires security layers then it MUST prefer the
SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS.
Spencer (minor): If prefer the mechanism is the right way to describe
this, I apologize, but I don't
Julien ÉLIE wrote:
Hi,
Hi Julien,
- 'ESMTP and LMTP Transmission Types Registration '
[...]
Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
Initial set of implementations is currently in the datatracker (see
below).
I do not know to whom I should
Samuel Weiler wrote:
On Wed, 18 Nov 2009, Alexey Melnikov wrote:
And for the common-use:
Registration of an IMAP keyword intended for common use (whether or
not they use the $ prefix) requires Expert Review [RFC5226]. IESG
appoints one or more Expert Reviewer, one of which
John-Luc Bakker wrote:
Dear all,
With regard to the recent discussion regarding RIM's recent IPR
disclosures, I understand the community's concerns regarding the
timeliness of the disclosure. As employees of companies we are bound by
confidentiality obligations and, in addition, cannot always
SM wrote:
At 11:34 AM 11/25/2009, The IESG wrote:
[...]
Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
That's a 404.
It was working yesterday. But the implementation report for RFC 3848 is
not there yet, it is in the datatracker.
Cullen Jennings wrote:
On October 8, the IESG approved the registration of
application/3gpp-ims+xml Media Type. On Nov 2, RIM filed an IPR
disclosure related to this at
https://datatracker.ietf.org/ipr/1219/
The associated patent, filed Oct 2008, is at
Cullen Jennings wrote:
I'd like to draw peoples attention to the IPR disclosure
https://datatracker.ietf.org/ipr/1213
on
http://tools.ietf.org/html/draft-montemurro-gsma-imei-urn
The associated patent seems to be
http://www.google.com/patents/about?id=O7qXEBAJ
Let me point out Mr.
Hi Samuel,
Thank you for the review.
Samuel Weiler wrote:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors.
Tony Hansen wrote:
One idea discussed over various beverages last night was based on an
observation about the high bar that most Proposed Standards have had
to pass over in order to become RFCs: many of them would not have
gotten to publication without having already gone through
Lars Eggert wrote:
Hi,
On 2009-11-1, at 1:00, Dave CROCKER wrote:
I haven't heard of an AD's doing this before.
most areas have been scheduling office hour slots during the week
for the last few years, for this and other purposes, but those
usually only get announced to the area lists.
Peter Saint-Andre wrote:
On 10/30/09 2:01 PM, Marc Petit-Huguenin wrote:
Roni Even wrote:
Henry,
I see travel budget and willingness to travel as part of the commitment
to participate in the work a working group.
I will not comment on this, but I wonder if ISOC could not have
I would like to offer some time in Hiroshima to help resolve DISCUSSes I
am holding. Currently I have time during the 09:00-11:30 slot on
Tuesday. If you want to talk to me during this slot, please send me an
email in advance.
___
Ietf mailing list
The IESG wrote:
The IESG has received a request from the Simple Authentication and
Security Layer WG (sasl) to consider the following document:
- 'Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family '
draft-ietf-sasl-gs2-17.txt as a Proposed Standard
The IESG plans to make a
Nicolas Williams wrote:
On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote:
On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote:
[...]
-- 1.2, last bullet:
What is the referent for this? Is there perhaps a missing word(s), or
maybe this paragraph
Nicolas Williams wrote:
On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote:
-- 2nd paragraph: ...increase the iteration count over time.
Can you elaborate on how this helps, and possibly offer guidance on
how implementations should use it?
Good point. With SCRAM as
Hi Ben,
Thank you for your comments. Responding to most of them below (I will
respond to the rest in a separate message).
On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background
On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote:
[...]
Minor issues:
[...]
-- section 4, first paragraph: ...as long as this alternative name doesn’t
conflict with any other hash function name from the IANA Hash Function
Textual Names registry.
What prevents future
On 9/23/09, Nicolas Williams nicolas.willi...@sun.com wrote:
On Wed, Sep 23, 2009 at 07:54:56PM +0200, Simon Josefsson wrote:
I have noticed an additional problem related to additional data in
SCRAM. RFC 4422 section 5 item 2b says:
b) An indication of whether the server is
Simon Josefsson wrote:
I support publication of draft-ietf-sasl-scram.
I have implemented SCRAM in a beta version of GNU SASL [1], see [2], so
I have good confidence that the document is in sufficiently good
technical condition.
I have not yet managed to do interop testing with anyone else
Simon Josefsson wrote:
John C Klensin john-i...@jck.com writes:
[...]
Because of the unrestricted UTF-8 problem, and without taking a
position on deprecating SASLprep, my inclination would be to
strengthen Simon's proposed requirement a bit to MUST use UTF-8
and SHOULD use SASLprep or at
David Harrington wrote:
If part of the purpose of the one-day pass is to let new attendees
understand how the IETF works, why don't we make attendance in the
newcomers' tutorial free - no paid attendance required, just
registration (for planning purposes).
I think this is a good idea.
I
ned+i...@mauve.mrochek.com wrote:
-- Section 4.2, paragraph 5: ... SHOULD use the structured comment
format shown above.
Why not MUST? Wouldn't violation of this requirement introduce
interoperability problems between different implementations?
It's a SHOULD because the WG believed that
[I am trying to avoid crossposting to 5 different mailing lists.]
---BeginMessage---
There have been two Last Call notices sent to the IETF for:
'Internet Mail Architecture' draft-crocker-email-arch as a
Proposed Standard
The IESG has received a concern about the intended publication
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Guidance on Interoperation and Implementation Reports '
draft-dusseault-impl-reports-02.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
John C Klensin wrote:
Hi.
This is a tiny nit, but, since -13 has not yet been posted...
A few of the references list organizations and not authors as
authors and should probably be fixed.[RFC5335] sort of leapt
out at me. A quick scan also turned up [RFC1652], but I have
not done a
The IESG wrote:
The IESG has received a request from the smime WG (smime) to consider
the following document:
- 'Cryptographic Message Syntax (CMS) '
RFC 3852 as a Draft Standard
No technical issues were raised during the first Last Call. However, the
Last Call failed to highlight two
John Leslie wrote:
Alexey Melnikov alexey.melni...@isode.com wrote:
The IESG wrote:
The IESG has received a request from the smime WG (smime) to consider
the following document:
- 'Cryptographic Message Syntax (CMS)' RFC 3852 as a Draft Standard
This appeared on the agenda
Randy Presuhn wrote:
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
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
draft-crocker-email-arch-11.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
Spencer Dawkins wrote:
Hi, Alexey,
Hi Spencer,
Thanks for the quick response back... now I can remember what I said
in the review ;-)
Spencer
Spencer Dawkins wrote:
[...]
5. Security Considerations
Extensions defined in this document deliberately don't provide a way
to modify
On Fri, Jan 9, 2009 at 5:26 PM, Scott Brim s...@employees.org wrote:
John C Klensin allegedly wrote on 1/9/09 11:11 AM:
--On Friday, January 09, 2009 8:36 -0500 Scott Brim
s...@employees.org wrote:
Hi Eliot.
I agree this is a problem ... but not one that we can solve
yet. At
Spencer Dawkins wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Ben Campbell wrote:
[Apologies for the lateness of this review. I somehow mis-recorded
the due date. Here's my review hoping late is better than never.]
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
1 - 100 of 166 matches
Mail list logo
