Hello Barry,
You wrote:
Hi, Jorge.
You may want to refer to Section 5.2 of RFC 5378, which addresses this
issue:
Each Contributor agrees that any statement in a Contribution, whether
generated automatically or otherwise, that states or implies that the
Contribution is confidential or
Reading through the document I fail to see the clearly stated restriction that
this is not to be used between the emergency caller's UA and the VSP/ASP's
network (for VSP/ASP routed calls) or between the UA and the PSAP (for directly
routed calls).
I was in the believe that the scope is
Personally, I think Informational is most appropriate (and probably easier),
but a paragraph or two of context, as well as corresponding adjustments, would
work as well.
Cheers,
On 13/07/2011, at 5:36 AM, Peter Saint-Andre wrote:
On 6/21/11 11:08 PM, Mark Nottingham wrote:
Generally, it's
Barry, I think that we should put a filter on the ietf.org that bounces
all messages with confidentiality notices.
I also think that we should enforce 77 columns max for text/plain when
there is no format=flowed option in the Content-Type.
--
] He who is tired of Weird Al is tired of
Let me explain why I'm planning to include this sub-section.
Why? Your explanation lacks substance, and further effort here is a
waste of time.
The document as it stands is just fine, except for one sentence that
needs rewording to make sense in English:
OLD
All IONs were republished whether
On 7/13/11 8:48 AM, Barry Leiba wrote:
The document says everything it needs to say. Let's publish it as it
is, and not spend more time trying to argue or explain anything.
+1
___
Ietf mailing list
Ietf@ietf.org
On Tue, Jul 12, 2011 at 05:39:49PM -0400, Barry Leiba wrote:
Each Contributor agrees that any statement in a Contribution, whether
generated automatically or otherwise, that states or implies that the
Contribution is confidential or subject to any privilege, can be disregarded
for all
Mykyta:
I don't think this debate has been advanced since the exchange on the
rfc-interest list, and my response remains the same.
Russ
On Jun 10, 2011, at 10:47 AM, Mykyta Yevstifeyev wrote:
Please consider these:
http://www.rfc-editor.org/pipermail/rfc-interest/2011-June/002518.html and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/13/2011 06:50 AM, Michael Richardson wrote:
Barry, I think that we should put a filter on the ietf.org that bounces
all messages with confidentiality notices.
Yes, and perhaps disclaimers/confidentiality notices should be standardized with
On 13/Jul/11 18:38, Marc Petit-Huguenin wrote:
On 07/13/2011 06:50 AM, Michael Richardson wrote:
Barry, I think that we should put a filter on the ietf.org that bounces
all messages with confidentiality notices.
Yes, and perhaps disclaimers/confidentiality notices should be standardized
13.07.2011 17:48, Barry Leiba wrote:
Let me explain why I'm planning to include this sub-section.
Why? Your explanation lacks substance, and further effort here is a
waste of time.
The document as it stands is just fine, except for one sentence that
needs rewording to make sense in English:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/13/2011 09:49 AM, Alessandro Vesely wrote:
On 13/Jul/11 18:38, Marc Petit-Huguenin wrote:
On 07/13/2011 06:50 AM, Michael Richardson wrote:
Barry, I think that we should put a filter on the ietf.org that bounces
all messages with
On 13 July 2011 08:51, Martin Rex m...@sap.com wrote:
Trying to gauge (rough) consensus by counting voiced opinions when an
issue has not been reliably determined to be non-technical and
non-procedural _is_ inappropriate.
Note that the point of the paper is saying that people feel that
there
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:
Francis et al,
not also that the protocol does support fragmentation and a 1004 frame
too large error.
Even the 1004 error does not carry an indication of what an acceptable
size is, so the client/tool/intermediary that receives a 1004 will
either have to fail or guess a smaller frames size -
Francis,
I agree with your points and would welcome a max frame size negotiation
header.
However, whilst an intermediary might legitimately change the fragmentation
of a frame it cannot merge complete messages. If, in your example, your
client limited itself to messages of a certain size then it
I agree that this would be very useful.
Would this be one frame size for both directions, or could it be specified
in each direction?
I'm a little wary of intermediaries being allowed to adjust this unless
they're only allowed to reduce the amount...
Len
www.lenholgate.com
-Original
Hi Len,
I agree that this would be very useful.
Would this be one frame size for both directions, or could it be specified
in each direction?
It should be done in both directions, assuming each party may have
different requirements..
I'm a little wary of intermediaries being allowed to
If you insist on that scope
I was in the believe that the scope is restricted only to PSAP-to-first
Responder, and PSAP-to-PSAP communication.
Then you can throw it away.
I certainly don't see it being used by an emergency calling UA, but in a 3GPP
like solution to emergency calling, there
Would this be one frame size for both directions, or could
it be specified
in each direction?
It should be done in both directions, assuming each party may have
different requirements..
That was my feeling on it.
I'm a little wary of intermediaries being allowed to adjust
this
Dear all,
I regret to say I have the same concerns expressed by Rui and Erminio about the
procedure adopted for this document that has brought so many discussions.
Anyway, probably because of the lack of a reasonable time (in my opinion) for
discussions about the previous document version (-04)
Francis,
Hi Len,
I agree with your points and would welcome a max frame size negotiation
header.
Ok, It shouldn't be a negotiation but an indication to accommodate
communication to each party.
However, whilst an intermediary might legitimately change the fragmentation
of a frame it cannot
On Jul 12, 2011, at 11:28 PM, Barry Leiba wrote:
I am increasingly seeing IETF participants posting messages to IETF
mailing lists, sending messages to chairs and ADs, and so on, where
their messages include confidentiality/security/legal notices at the
bottom.
The first ones have shown
I'm looking for a room at the Hilton ideally at the IETF rate. Please
send me a direct e-mail if you have a room that you no longer require.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 7/12/2011 4:03 PM, Greg Wilkins wrote:
think there is an important message there for the IETF, because the
establishment of consensus is not by any objective measure and this
science says that subjective measures can be influe
The real issue is proving the consensus was reasonable after the
Replacing a widely used term (on the wire) with term that folks will
not understand does not seem to me personally to be a benefit.
In terms of this document, I do not see a problem with the usage as it
is. This is not a protocol document. The use of the current term in
this context seems
On Jul 11, 2011, at 10:58 PM, Brian E Carpenter wrote:
We quite often discuss here how to judge rough consensus. In a completely
non-IETF context, I came upon a reference to an article published in 2007
with the catchy title Inferring the Popularity of an Opinion From Its
Familiarity: A
Hi, Joel,
On 7/13/2011 10:31 AM, Joel M. Halpern wrote:
Replacing a widely used term (on the wire) with term that folks will
not understand does not seem to me personally to be a benefit.
The problem is that on the wire is ambiguous. Many people think they
know what it means definitively,
On 07/13/2011 11:00, Fred Baker wrote:
To my mind, it's not a matter of voting (how many people think A, how many
people think B, ...) and not a matter of volume (which would accept a
filibuster as a showstopper). It's a question of the preponderance of opinion
(agreement, harmony,
On 7/13/2011 1:31 PM, Joel M. Halpern wrote:
Replacing a widely used term (on the wire) with term that folks will
not understand does not seem to me personally to be a benefit.
I think Joe's point is that it's widely used as a concept, but what
it means specifically in this document is not
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents,
including many RFCs. It would also state for clarity that in this
On 7/13/2011 2:34 PM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents,
including many RFCs. It
On 7/13/2011 11:34 AM, Joel M. Halpern wrote:
As I said in my earlier note proposing responses to Joe, we would be
happy to some text in the front clarifying the usage. Quoting from my
earlier email:
This text would note that it is a widely used term in IETF documents,
including many RFCs. It
The process seems to be today what I call Consensus by Osmosis.
People get tired of the highly mixed discipline subjective
philosophies, many times subject to personal agendas, and conflict of
interest, many get shouted out even to the extent of ignorance at the
suggestion of key cogs. So even
On Jul 13, 2011, at 2:00 PM, Fred Baker wrote:
On Jul 11, 2011, at 10:58 PM, Brian E Carpenter wrote:
We quite often discuss here how to judge rough consensus. In a completely
non-IETF context, I came upon a reference to an article published in 2007
with the catchy title Inferring the
On Jul 13, 2011, at 12:55 PM, Keith Moore wrote:
On Jul 13, 2011, at 2:00 PM, Fred Baker wrote:
On Jul 11, 2011, at 10:58 PM, Brian E Carpenter wrote:
We quite often discuss here how to judge rough consensus. In a completely
non-IETF context, I came upon a reference to an article
On Jul 13, 2011, at 4:11 PM, Joel Jaeggli wrote:
There's also a common tendency of some kinds of groups to categorically
dismiss the opinions of those that they see as outliers, even to the point
of diminishing their numbers. If one of those objecting happens to defend
his viewpoint
Sorry, I apparently missed part of your earlier note.
Would text like:
This document uses the term on-the-wire to talk about the
information used by routing systems. This term is widely used in IETF
RFCs,but is used in several different ways. In this document, it is
used to refer both to
Italo,
The design team report
(http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm),
with Huub's name as an author, details a plan for MPLS-TP OAM which the MPLS WG
has followed to this day. I think the report is compelling evidence that the
claim that a packet
I don't understand your description of the problem.
As you quote, the document clearly states its scope.
So, when we then define the term on-the-wire, I don't think we need to
restate the scope definition. It woudl seem coutner-productive.
Yours,
Joel
On 7/13/2011 2:58 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 1:44 PM, Joel M. Halpern wrote:
Sorry, I apparently missed part of your earlier note.
Would text like:
This document uses the term on-the-wire to talk about the information
used by routing systems. This term is widely used in IETF RFCs,but is
used in several different
Hi, Joel,
On 7/13/2011 1:58 PM, Joel M. Halpern wrote:
I don't understand your description of the problem.
As you quote, the document clearly states its scope.
So, when we then define the term on-the-wire, I don't think we need to
restate the scope definition. It woudl seem coutner-productive.
You wording seems to induce confusion.
Of course the routing message content is part of the message
on-the-wire. It is the content of the message. It is in fact a
significant part of what is being protected.
What is NOT part of the scope, and which the text says is not part of
the scope,
On 7/12/11 2:06 PM, Martin Rex wrote:
Peter Saint-Andre wrote:
On 6/21/11 11:08 PM, Mark Nottingham wrote:
Generally, it's hard for me to be enthusiastic about this proposal,
for a few reasons. That doesn't mean it shouldn't be published, but I
do question the need for it to be Standards
On 7/13/11 5:35 AM, Mark Nottingham wrote:
Personally, I think Informational is most appropriate (and probably
easier), but a paragraph or two of context, as well as corresponding
adjustments, would work as well.
Personally I'm not wedded to Standards Track for this document, and
neither are
Italo,
Comments inline.
Thanks,
John
Sent from my iPhone
-Original Message-
From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it]
Sent: Wednesday, July 13, 2011 2:04 PM
To: John E Drake; david.i.al...@ericsson.com; rco...@ptinovacao.pt;
ietf@ietf.org;
--On Wednesday, July 13, 2011 09:38 -0700 Marc Petit-Huguenin
petit...@acm.org wrote:
...
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to make automatic
processing easier so receivers of this kind of notice
(mailing-list or other) can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/13/2011 03:19 PM, John C Klensin wrote:
--On Wednesday, July 13, 2011 09:38 -0700 Marc Petit-Huguenin
petit...@acm.org wrote:
...
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to
Randall Gellens wrote:
I'm not a lawyer and I don't play one on TV or the net, so I likely
don't understand the situation. As a point of possibly interesting
information, once upon a time, at a training session held by a lawyer
regarding how to protect confidential information, we were
Hi, Joel,
On 7/13/2011 2:26 PM, Joel M. Halpern wrote:
You wording seems to induce confusion.
Of course the routing message content is part of the message
on-the-wire. It is the content of the message. It is in fact a
significant part of what is being protected.
What is NOT part of the scope,
I am not sure what you are asking.
KARP is never concerned with whether the party is authorized to send the
information it is sending.
KARP is concerned with assuring that the information received is either
the information sent, or recognizably NOT the information sent (so it
can be
Hi, Joel,
On 7/13/2011 4:24 PM, Joel M. Halpern wrote:
I am not sure what you are asking.
KARP is never concerned with whether the party is authorized to send the
information it is sending.
Right - that's bullet 3.
KARP is concerned with assuring that the information received is either
the
I am not sure we are in sync, but it looks clsoe enough that proposed
introductory text would be veyr helpful at this point.
Yours,
Joel
On 7/13/2011 7:59 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 4:24 PM, Joel M. Halpern wrote:
I am not sure what you are asking.
KARP is never concerned
Ever since, I've wondered if these notices were set up by someone
who is a lawyer and does understand the situation, or if they were
set up by someone who saw others do it, or heard that this sort of
thing was needed.
It's clueless cargo cult lawyering. I blogged on it in January:
Yes, and perhaps disclaimers/confidentiality notices should be
standardized with their own MIME type to make automatic processing
easier so receivers of this kind of notice (mailing-list or other)
can respect the wishes of the sender.
That respect would of course be demonstrated by rejecting or
John Levine wrote:
It's clueless cargo cult lawyering. I blogged on it in January:
http://jl.ly/Internet/confid.html
That tells me a lot about the competence of some lawyers. A law firm
asked me some time ago to implement a system on their MS Exchange server
to automatically add such
Erminio Hi,
I belong to an Operator, I strongly agree with Greg.
Regards
Medel
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
Greg Mirsky
Sent: Thursday, July 14, 2011 10:50 AM
To: erminio.ottone...@libero.it
Cc: m...@ietf.org;
81st IETF Meeting
Quebec City, Canada
July 24 - 29, 2011
Host: Research In Motion (RIM)
Register online at: http://www.ietf.org/meetings/81/
Registration - Early Bird Cut-off is July 15, 2011
Early-Bird: $650 USD, if paid in full prior to 1700 PDT July 15.
Late: $800 USD if paid
The IESG has approved the following document:
- 'Design Considerations for Session Initiation Protocol (SIP) Overload
Control'
(draft-ietf-soc-overload-design-08.txt) as an Informational RFC
This document is the product of the SIP Overload Control Working Group.
The IESG contact persons are
The Internet Engineering Task Force is seeking an RFC Series Editor (RSE). The
RSE has overall responsibility
for the quality, continuity, and evolution of the Request for Comments (RFC)
Series, the Internet's seminal
technical standards and publications series. The position has operational
A new Request for Comments is now available in online RFC libraries.
RFC 6131
Title: Sieve Vacation Extension: Seconds Parameter
Author: R. George, B. Leiba
Status: Standards Track
Stream: IETF
Date: July 2011
A new Request for Comments is now available in online RFC libraries.
RFC 6132
Title: Sieve Notification Using Presence Information
Author: R. George, B. Leiba
Status: Standards Track
Stream: IETF
Date: July 2011
A new Request for Comments is now available in online RFC libraries.
RFC 6133
Title: Sieve Email Filtering: Use of
Presence Information with Auto-Responder Functionality
Author: R. George, B. Leiba,
A. Melnikov
A new Request for Comments is now available in online RFC libraries.
RFC 6134
Title: Sieve Extension: Externally Stored Lists
Author: A. Melnikov, B. Leiba
Status: Standards Track
Stream: IETF
Date: July 2011
A new Request for Comments is now available in online RFC libraries.
BCP 163
RFC 6303
Title: Locally Served DNS Zones
Author: M. Andrews
Status: Best Current Practice
Stream: IETF
Date: July 2011
A new Request for Comments is now available in online RFC libraries.
RFC 6304
Title: AS112 Nameserver Operations
Author: J. Abley, W. Maton
Status: Informational
Stream: IETF
Date: July 2011
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 6305
Title: I'm Being Attacked by PRISONER.IANA.ORG!
Author: J. Abley, W. Maton
Status: Informational
Stream: IETF
Date: July 2011
A new Request for Comments is now available in online RFC libraries.
RFC 6311
Title: Protocol Support for High Availability
of IKEv2/IPsec
Author: R. Singh, Ed.,
G. Kalyani, Y. Nir,
Y.
A new Request for Comments is now available in online RFC libraries.
RFC 6276
Title: DHCPv6 Prefix Delegation for Network
Mobility (NEMO)
Author: R. Droms, P. Thubert,
F. Dupont, W. Haddad,
A new Request for Comments is now available in online RFC libraries.
RFC 6322
Title: Datatracker States and Annotations for
the IAB, IRTF, and Independent Submission
Streams
Author: P. Hoffman
Status:
Greetings All,
Please note that the RFC Editor will be hosting office hours at IETF
81. The RFC Editor desk will be located in the IETF registration area
and will be staffed as follows:
RFC Production Center
Monday - Wednesday
9:00 - 4:30
Independent Submissions Editor (ISE) -- Nevil
71 matches
Mail list logo
