On 2 mar 2012, at 00:00, Barry Leiba wrote:
> What I'm interested in community input on is whether the mechanism of
> transferring the information back and forth between the two, and having SMTP
> protocol get involved in inspecting and altering header fields is a good
> thing.
No, not chang
> 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 important capability for those
> who need a
Total of 183 messages in the last 7 days.
script run at: Fri Mar 2 00:53:02 EST 2012
Messages | Bytes| Who
+--++--+
8.20% | 15 | 7.44% | 110386 | sc...@kitterman.com
6.56% | 12 | 6.44% |95538 | sant9...@gmai
> What I'm interested in community input on is whether the mechanism of
> transferring the information back and forth between the two, and
> having SMTP protocol get involved in inspecting and altering header
> fields is a good thing.
you're kidding, right? talk about primrose path. did you not
--On Thursday, March 01, 2012 19:38 +0100 "Sprecher, Nurit (NSN
- IL/Hod HaSharon)" wrote:
> Draft-betts asks a code point for a document which is not
> mature and not agreed yet. Usually we do not issue last call
> for a document in such a condition!
Actually, we do that fairly regularly. H
Peter Saint-Andre wrote:
>On 3/1/12 12:00 PM, Scott Kitterman wrote:
>> On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
>>> The IESG has received a request from the Applications Area Working
>Group
>>> WG (appsawg) to consider the following document:
>>> - 'Deprecating Use of the "X-" P
Barry Leiba wrote:
>
> Oh, it's absolutely true that if one is to define this sort of thing as a
> combination of SMTP protocol and message header fields, that should be done
> in a single specification. What I'm interested in community input on is
> whether the mechanism of transferring the inf
Nurit:
Some people are using the lack of a code point as the reason that the cannot
support the ITU-T document. My approach tells the ITU-T that a code point is
available to them IFF they are able to reach consensus. The removes IETF from
the discussion. This creates a situation where G.8113
> From: barryleiba.mailing.li...@gmail.com
> [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
> Sent: Thursday, March 01, 2012 3:01 PM
> To: Murray S. Kucherawy
> Cc: ietf@ietf.org
> Subject: Re: Last Call: (Simple Mail
> Transfer Protocol extension for Message Transfer Prior
At 11:14 01-03-2012, Murray S. Kucherawy wrote:
Would "ADMD" and an informative reference to RFC5598 be more appropriate?
There exist cases in which the administrator of domain name employing
[SPF] for announcing sending practices may want to know when messages are
received via unauthorize
--On Thursday, March 01, 2012 18:39 + Stewart Bryant
wrote:
>...
>> FWIW, this seems entirely appropriate to me. If we do it this
>> way, I think it is important to note --for the benefit of
>> those more historically involved with the ITU and others--
>> that we routinely block our own do
Oh, it's absolutely true that if one is to define this sort of thing as a
combination of SMTP protocol and message header fields, that should be done
in a single specification. What I'm interested in community input on is
whether the mechanism of transferring the information back and forth
between
On 3/1/12 12:00 PM, Scott Kitterman wrote:
> On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
>> The IESG has received a request from the Applications Area Working Group
>> WG (appsawg) to consider the following document:
>> - 'Deprecating Use of the "X-" Prefix in Application Protocols'
>>
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM
> Sent: Thursday, March 01, 2012 1:36 PM
> To: ietf@ietf.org
> Cc: Alexey Melnikov
> Subject: Re: Last Call: (Simple
> Mail Transfer Protocol extension for Message Transfer Priorities) to
> Pr
Hi Barry,
At 13:53 01-03-2012, Barry Leiba wrote:
It certainly does, in the first paragraph:
I missed that.
Section 3:
7. The PRIORITY extension is valid for the submission service
[RFC6409] and LTMP [RFC2033].
And that one.
This is my major concern about this protocol as well,
WFM. Thanks, Peter.
On 02/03/2012, at 4:50 AM, Peter Saint-Andre wrote:
>
>
> On 2/21/12 11:10 AM, IESG Secretary wrote:
>> A modified charter has been submitted for the Hypertext Transfer
>> Protocol Bis (httpbis) working group in the Applications Area of the
>> IETF. The IESG has not made
Also, because it's not publicly visible, here's my PROTO writeup for
this document:
The publication of draft-melnikov-smtp-priority as a Proposed Standard
is requested by an individual contributor.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational,
> This draft specifies a SMTP extension. The IANA Considerations does not
> mention registration in the the SMTP Service Extensions registry.
It certainly does, in the first paragraph:
This specification requests IANA to add the PRIORITY SMTP extension
to the "SMTP Service Extensions" regi
>> >> "Security issues with respect to these reports are similar to those
>> >> found in [DSN]."
>> >>
>> >> The reference to DSN could be normative.
>> >
>> > Security Considerations are never normative, so I'm not sure I agree
>> > that this should be.
>>
>> It should. Just because the Secu
At 16:42 29-02-2012, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Simple Mail Transfer Protocol extension for Message Transfer
Priorities'
as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
On Thursday, March 01, 2012 04:01:20 PM Barry Leiba wrote:
...
> >> In Section 6:
> >>
> >> "Security issues with respect to these reports are similar to those
> >>found in [DSN]."
> >>
> >> The reference to DSN could be normative.
> >
> > Security Considerations are never normative, so I'
>> "current: The field is in current use
>>
>> deprecated: The field is in current use but its use is
>> discouraged"
>>
>> The difference in "current use" can end up being problematic for the
>> designated expert.
>
> A number of registries are using this wording already and there'
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 already raised.
First, two additional points:
Russ,
I propose to simply re-discuss it when and IFF G.8113.1 is mature and
approved...
Best regards,
Nurit
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Russ Housley
Sent: Thursday, March 01, 2012 9:12 PM
To: IETF
Subject: Re: Last Call:
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM
> Sent: Wednesday, February 29, 2012 10:27 PM
> To: ietf@ietf.org
> Subject: Re: Last Call: (SPF
> Authentication Failure Reporting using the Abuse Report Format) to
> Proposed Standard
As fo
>>> Right now, there is no ITU-T approved document to reference.
>>> I am certainly not an expert on ITU-T process, but my
>>> understanding is that earliest that we could see an approved
>>> G.8113.1 is December 2012. My point is that we don't want to
>>> assign a code point until the ITU-T appro
On Mar 1, 2012, at 10:05 AM, SM wrote:
> At 09:50 01-03-2012, Peter Saint-Andre wrote:
>> Stephen and I just had a chat about this matter. He and I came up with a
>> proposed paragraph to add after that list of bullet points:
>>
>> In the initial phase of work on HTTP/2.0, new proposals
>> fo
On Mar 1, 2012, at 10:01 AM, Nick Hilliard wrote:
> Can I suggest you also include authorization capabilities as a core
> component of this. It's not much use to have people able to authenticate
> themselves to a system if that system doesn't also provide a framework for
> allowing the server-side
On Thursday, March 01, 2012 10:47:50 AM The IESG wrote:
> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'Deprecating Use of the "X-" Prefix in Application Protocols'
>as a Best Current Practice
>
> The IESG plans
Russ,
The LS370 version of G.8113.1 has been sent to the ITU-T Nov 2012
meeting (a.k.a. WTSA) for further discussion. At this point, no one can
tell if it will be approved. As the level of stability and maturity of
G.8113.1 will not be changed between now and Nov, the opinions made by
ITU-T member
[ no hat ]
On 3/1/12 11:01 AM, Nick Hilliard wrote:
> On 01/03/2012 17:50, Peter Saint-Andre wrote:
>> Stephen and I just had a chat about this matter. He and I came up with a
>> proposed paragraph to add after that list of bullet points:
>>
>>In the initial phase of work on HTTP/2.0, new prop
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott
> Kitterman
> Sent: Thursday, March 01, 2012 6:22 AM
> To: ietf@ietf.org
> Subject: Re: Last Call: (SPF
> Authentication Failure Reporting using the Abuse Report Format) to
> Proposed Stan
On 3/1/12 11:05 AM, SM wrote:
> At 09:50 01-03-2012, Peter Saint-Andre wrote:
>> Stephen and I just had a chat about this matter. He and I came up with a
>> proposed paragraph to add after that list of bullet points:
>>
>>In the initial phase of work on HTTP/2.0, new proposals
>>for authent
On 01/03/2012 18:28, John C Klensin wrote:
--On Thursday, March 01, 2012 13:02 -0500 Russ Housley
wrote:
Loa:
Right now, there is no ITU-T approved document to reference.
I am certainly not an expert on ITU-T process, but my
understanding is that earliest that we could see an approved
G.811
Draft-betts asks a code point for a document which is not mature and not
agreed yet. Usually we do not issue last call for a document in such a
condition!
And in addition, draft-betts has many issues that must be resolved
first.
For example it must be clear for what the code point is requested.
Dr
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM
> Sent: Thursday, March 01, 2012 10:01 AM
> To: ietf@ietf.org
> Subject: Re: Last Call: (SPF
> Authentication Failure Reporting using the Abuse Report Format) to
> Proposed Standard
>
> At 08
To make sure that my concerns are not missed, I attach them:
--
Hi,
I cannot support the publication of the document in its current version.
I have the following concerns:
* It is indicated that the channel is intended to be used to carry
Ethernet based OAM messages. It is not clear why t
--On Thursday, March 01, 2012 13:02 -0500 Russ Housley
wrote:
> Loa:
>
> Right now, there is no ITU-T approved document to reference.
> I am certainly not an expert on ITU-T process, but my
> understanding is that earliest that we could see an approved
> G.8113.1 is December 2012. My point is
On 3/1/2012 6:22 AM, Scott Kitterman wrote:
I don't think it's efficient at all to put this draft on hold and revive it
later for non-technical reasons.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@i
At 09:50 01-03-2012, Peter Saint-Andre wrote:
Stephen and I just had a chat about this matter. He and I came up with a
proposed paragraph to add after that list of bullet points:
In the initial phase of work on HTTP/2.0, new proposals
for authentication schemes can be made. The WG will
At 08:53 01-03-2012, Scott Kitterman wrote:
No. The downref is correct. Downrefs are allowed, but have to be reviewed
(AIUI). I was saying that I think the downref is safe and appropriate in this
The question would be whether the downward reference is in accordance
with BCP 97. It is up to
Russ,
Independently of that point, draft-betts in its current version has many
issues
Many clarifications are needed before it can be consideredplease see
my mail for the details.
Best regards,
Nurit
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Loa:
Right now, there is no ITU-T approved document to reference. I am certainly
not an expert on ITU-T process, but my understanding is that earliest that we
could see an approved G.8113.1 is December 2012. My point is that we don't
want to assign a code point until the ITU-T approves their
On 01/03/2012 17:50, Peter Saint-Andre wrote:
> Stephen and I just had a chat about this matter. He and I came up with a
> proposed paragraph to add after that list of bullet points:
>
>In the initial phase of work on HTTP/2.0, new proposals
>for authentication schemes can be made. The WG
+1
On Thu, Mar 1, 2012 at 9:50 AM, Peter Saint-Andre wrote:
>
>
> On 2/21/12 11:10 AM, IESG Secretary wrote:
>> A modified charter has been submitted for the Hypertext Transfer
>> Protocol Bis (httpbis) working group in the Applications Area of the
>> IETF. The IESG has not made any determinati
On 2/21/12 11:10 AM, IESG Secretary wrote:
> A modified charter has been submitted for the Hypertext Transfer
> Protocol Bis (httpbis) working group in the Applications Area of the
> IETF. The IESG has not made any determination as yet. The modified
> charter is provided below for informatio
Hi Russ,
I am not K.Y., but to me it seems at the moment as a very theoretical
question.
If the G.8113.1 document is stable and approved, we can re-issue an IETF
LC for a
better version of draft-betts that resolves my and others' comments that
I sent earlier today and the IETF can make the decisio
Hi Russ,
I am not K.Y., but to me it seems at the moment as a very theoretical
question.
If the document is stable and approved, we can re-issue an IETF LC for a
better version of draft-betts that resolves my and others' comments that
I sent earlier today and the IETF can make the decision then.
A
On Thursday, March 01, 2012 07:53:48 AM SM wrote:
...
> At 06:22 01-03-2012, Scott Kitterman wrote:
> >IESG. It includes SPF specifics (although it doesn't require a normative
> >reference to RFC 4408, so there's no downref issue with it), so I think
> >that in the context of authentication failur
Russ,
I'm not KY, but I feel that your question is a bit loaded.
Certainly if the document is reviewed and approved by the IETF/IESG
it would be no problem to support the assignment of a ACh Type.
But I can't see that approval by some other instance actually carry
the same merit - so exactly wh
lör 2012-02-25 klockan 19:23 +0100 skrev Julian Reschke:
> Well, I'm one of the editors of the authentication framework spec, so if
> there's something wrong with it, I'd like to know.
Only the thing said earluer
- Define how servers may influence the visible appearance of the login
action
- Pe
lör 2012-02-25 klockan 17:44 + skrev Stephen Farrell:
> I don't think fixing or changing the framework will give us better
> auth schemes by itself. (Better auth schemes may or may not require
> changes to the framework, I dunno.)
Obviously not. Fixing the framework giving better use of auth
lör 2012-02-25 klockan 14:13 + skrev Stephen Farrell:
> I don't agree with you there - the perceived low probability that
> something will be deployed is a real disincentive here. We have had
> people wanting to do work on this and have been told there's no point
> because it won't get adopted
tis 2012-02-21 klockan 19:50 +0100 skrev Julian Reschke:
> Well, we have an existing authentication framework. It would be
> interesting to find out what's missing from it.
My take is better secure authentication schemes (not plaintext password
based) which is cleanly specified to a level that im
There is one other thing I would add to auth:
Ability for a challenger to identify itself, and for a response to
target a challenger.
Currently with chained proxies, it's not possible to reliably pass
challenges and creds back to the client. A proxy looking at a request
would need to maint
At 06:09 01-03-2012, Barry Leiba wrote:
Keep in mind that the charter has these two items:
Ok.
2. SPF is widely deployed in the real world. Information about
Is a protocol considered by the IETF to be widely deployed based on
deployment of implementations? For example, an IPv6 survey (
KY:
Would you support the assignment to an approved G.8113.1? That is, if the
document contained a normative reference to the approved G.8113.1, then the
document that makes the code point allocations would sit in the RFC Editor
queue until the ITU-T reaches consensus and approves G.8113.1.
R
Hi,
I cannot support the publication of the document in its current version.
I have the following concerns:
*It is indicated that the channel is intended to be used to
carry Ethernet based OAM messages. It is not clear why there is a need
for ACH. PWs can be used to transmit Eth
Great!
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Kyung-Yeop Hong (hongk)
Sent: Thursday, March 01, 2012 5:14 PM
To: ietf@ietf.org
Subject: Re: Last Call:
(Allocation of an Associated
Channel Code Point for Use byITU-T Ethernet based OAM)
No/do not support.
One of the issues with G.8113.1 in LS370 is its stability and maturity.
That was one of the reasons why it was not approved.
The Ethernet based OAM protocol documented in the LS370 version is
intended to be deployed for MPLS networks. I think the IETF has a duty
to ensure that
On Wednesday, February 29, 2012 10:26:41 PM SM wrote:
> At 16:46 29-02-2012, The IESG wrote:
> >The IESG has received a request from the Messaging Abuse Reporting Format
> >WG (marf) to consider the following document:
> >- 'SPF Authentication Failure Reporting using the Abuse Report Format'
> >
>
> The MARF charter [1] does not contain any mention of "SPF Authentication
> Failure Reporting using the Abuse Report Format" as a deliverable. There is
> no mention of SPF in the charter.
Keep in mind that the charter has these two items:
2) The group will produce an informational document det
- Original Message -
From: "Murray S. Kucherawy"
To:
Cc:
Sent: Thursday, March 01, 2012 5:43 AM
> - Appendix D: "This appendix and its subsections are informative." I think
that (a) any appendix is informative, because normative text doesn't belong in
an appendix; and (b) the normative
63 matches
Mail list logo
