Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 166 messages in the last 7 days.
 
script run at: Fri Jul 15 00:53:01 EDT 2011
 
Messages   |  Bytes| Who
+--++--+
  3.01% |5 |  8.90% |   127627 | neil.2.harri...@bt.com
  5.42% |9 |  5.11% |73305 | j...@joelhalpern.com
  4.22% |7 |  5.41% |77548 | erminio.ottone...@libero.it
  4.82% |8 |  4.29% |61563 | to...@isi.edu
  4.82% |8 |  3.82% |54829 | evniki...@gmail.com
  2.41% |4 |  5.57% |79869 | david.i.al...@ericsson.com
  2.41% |4 |  5.24% |75130 | jdr...@juniper.net
  4.22% |7 |  2.50% |35895 | julian.resc...@gmx.de
  1.20% |2 |  4.35% |62421 | gregimir...@gmail.com
  3.01% |5 |  2.48% |35639 | stpe...@stpeter.im
  1.20% |2 |  3.48% |49877 | nurit.sprec...@nsn.com
  2.41% |4 |  2.09% |30001 | len.holg...@gmail.com
  2.41% |4 |  1.83% |26193 | brian.e.carpen...@gmail.com
  2.41% |4 |  1.59% |22845 | barryle...@computer.org
  2.41% |4 |  1.52% |21857 | petit...@acm.org
  2.41% |4 |  1.41% |20213 | iljit...@muada.com
  1.81% |3 |  1.70% |24326 | fran...@aspl.es
  1.81% |3 |  1.35% |19401 | mo...@network-heretics.com
  1.81% |3 |  1.31% |18810 | gr...@intalio.com
  1.81% |3 |  1.23% |17654 | ra...@qualcomm.com
  1.81% |3 |  1.16% |16658 | joe...@bogus.com
  1.81% |3 |  1.01% |14419 | m...@sap.com
  1.81% |3 |  0.95% |13630 | m...@sandelman.ca
  1.20% |2 |  1.16% |16620 | turchanyi.g...@gmail.com
  0.60% |1 |  1.68% |24073 | rco...@ptinovacao.pt
  1.20% |2 |  0.98% |14087 | hsan...@isdg.net
  0.60% |1 |  1.56% |22352 | tnad...@lucidvision.com
  1.20% |2 |  0.93% |13393 | hous...@vigilsec.com
  1.20% |2 |  0.93% |13349 | nomcom-ch...@ietf.org
  1.20% |2 |  0.85% |12136 | otr...@employees.org
  1.20% |2 |  0.80% |11467 | hex...@gmail.com
  1.20% |2 |  0.77% |11097 | w...@mti-systems.com
  1.20% |2 |  0.77% |10977 | rog...@gmail.com
  1.20% |2 |  0.74% |10587 | ves...@tana.it
  1.20% |2 |  0.72% |10329 | samirs.li...@gmail.com
  1.20% |2 |  0.67% | 9653 | mo...@necom830.hpcl.titech.ac.jp
  1.20% |2 |  0.65% | 9355 | i...@aliax.net
  0.60% |1 |  1.24% |17756 | me...@globetel.com.ph
  1.20% |2 |  0.59% | 8485 | john-i...@jck.com
  1.20% |2 |  0.58% | 8268 | jo...@iecc.com
  0.60% |1 |  1.10% |15749 | alessandro.dalessan...@telecomitalia.it
  0.60% |1 |  0.89% |12769 | cntre...@gmail.com
  0.60% |1 |  0.76% |10857 | m...@mnot.net
  0.60% |1 |  0.74% |10606 | keith.dr...@alcatel-lucent.com
  0.60% |1 |  0.66% | 9523 | swal...@cisco.com
  0.60% |1 |  0.65% | 9388 | nar...@us.ibm.com
  0.60% |1 |  0.64% | 9208 | stbry...@cisco.com
  0.60% |1 |  0.62% | 8910 | tramm...@tik.ee.ethz.ch
  0.60% |1 |  0.58% | 8258 | hannes.tschofe...@gmx.net
  0.60% |1 |  0.52% | 7509 | hideki.endo...@hitachi.com
  0.60% |1 |  0.52% | 7431 | cb.li...@gmail.com
  0.60% |1 |  0.51% | 7246 | b...@nostrum.com
  0.60% |1 |  0.48% | 6828 | david.bl...@emc.com
  0.60% |1 |  0.43% | 6179 | quit...@neclab.eu
  0.60% |1 |  0.43% | 6156 | ma...@isc.org
  0.60% |1 |  0.42% | 6082 | f...@cisco.com
  0.60% |1 |  0.42% | 5979 | t...@ecs.soton.ac.uk
  0.60% |1 |  0.41% | 5871 | b...@secret-wg.org
  0.60% |1 |  0.41% | 5840 | do...@dougbarton.us
  0.60% |1 |  0.40% | 5782 | behcetsarik...@yahoo.com
  0.60% |1 |  0.40% | 5701 | dwor...@avaya.com
  0.60% |1 |  0.38% | 5472 | m...@sabahattin-gucukoglu.com
  0.60% |1 |  0.38% | 5469 | moha...@niif.hu
  0.60% |1 |  0.37% | 5238 | huubatw...@gmail.com
  0.60% |1 |  0.36% | 5153 | rbar...@bbn.com
  0.60% |1 |  0.35% | 5035 | rsoc-ch...@iab.org
  0.60% |1 |  0.35% | 4997 | d...@dcrocker.net
  0.60% |1 |  0.34% | 4944 | d...@cridland.net
  0.60% |1 |  0.34% | 4890 | tglas...@earthlink.net
  0.60% |1 |  0.32% | 4620 | a...@anvilwalrusden.com
  0.60% |1 |  0.31% | 4481 | jdfalk-li...@cybernothing.org
  0.60% |1 |  0.30% | 4347 | mic...@arneill-py.sacramento.ca.us
  0.60% |1 |  0.28% | 3985 | psangs...@gmail.com
+--++--+
100.00% |  166 |100.00% |  1434197 | Total
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Confidentiality notices on email messages

[Worley, Dale R (Dale)]

> From: John C Klensin [john-i...@jck.com]
> 
> Randall Gellens  wrote:
> 
> > At 6:19 PM -0400 7/13/11, John C Klensin wrote:
> >
> >>Content-type: text/noise;
> >>noise-type="bogus-legal-disclaimer", charset=...
> >
> > Ooh, I like this proposal.  We can also have noise-types for
> > exhortations to not print the email.
> 
> If one starts down that path, there is a real possibility for a
> semantically-rich environment.  For example, consider a noise
> type for flaming, repetitive, responses to a topic on the IETF
> list.  One could also very efficiently reflect what I assume was
> the intent of a recent observation on the list with
> noise-type="hitler" :-(

I, personally, am looking forward to the extended discussion regarding
the proper procedures for deciding upon and registering new values of
the "noise-type" parameter.  I believe that there are a number of
subtle conceptual and syntactic distinctions that need to be clearly
delineated, with due consideration for global cultural differences.

Dale
--
cephalopod9 wrote:
Only on Xkcd can you start a topic involving Hitler and people spend
the better part of half a dozen pages arguing about the quality of
Operating Systems.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Barry Leiba]

>>>    Content-type: text/noise;
>>>    noise-type="bogus-legal-disclaimer", charset=...
>>
>> Ooh, I like this proposal.  We can also have noise-types for
>> exhortations to not print the email.
>
> If one starts down that path, there is a real possibility for a
> semantically-rich environment.  For example, consider a noise
> type for flaming, repetitive, responses to a topic on the IETF
> list.  One could also very efficiently reflect what I assume was
> the intent of a recent observation on the list with
> noise-type="hitler" :-(

I think you guys could develop a nice, crisp spec for this over the
coming 8.5 months.

Barry
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed St

[Joel Jaeggli]

To the extent that this particular debate (that of the nature scope and success 
or failure of the liaison effort) has been going on for some time:

* it's not going to be resolved.
* rehashing the history of how we came to this point it advances what agenda?

It would seems timely in the IETF last call to focus the line of criticism on 
the merits or lack thereof of the draft as it stands, not on how we arrived 
here.

joel


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[John C Klensin]

--On Thursday, July 14, 2011 11:00 -0700 Randall Gellens
 wrote:

> At 6:19 PM -0400 7/13/11, John C Klensin wrote:
> 
>>Content-type: text/noise;
>>noise-type="bogus-legal-disclaimer", charset=...
> 
> Ooh, I like this proposal.  We can also have noise-types for
> exhortations to not print the email.

If one starts down that path, there is a real possibility for a
semantically-rich environment.  For example, consider a noise
type for flaming, repetitive, responses to a topic on the IETF
list.  One could also very efficiently reflect what I assume was
the intent of a recent observation on the list with
noise-type="hitler" :-(

   john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Randall Gellens]

At 6:19 PM -0400 7/13/11, John C Klensin wrote:


   Content-type: text/noise; noise-type="bogus-legal-disclaimer",
 charset=...


Ooh, I like this proposal.  We can also have noise-types for 
exhortations to not print the email.


--
Randall Gellens
Opinions are personal;facts are suspect;I speak for myself only
-- Randomly selected tag: ---
Note that although IBM 'invented' virtual memory in 1972 it had
been available in a multi-processor multi-tasking environment on
the Burroughs B5000 line since 1963 and the B6000 line since 1968.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defectindication for MPLS Transport Profile) to Proposed Standard

[Sprecher, Nurit (NSN - IL/Hod HaSharon)]

Rui,
I kindly propose not to refer in this context to the Feb2011 WP3 and
SG15 plenary meetings
Very unfortunately, it was far away from being a technical
discussion.or technical poll. 
Therefore it cannot be a reference to any argument in this context.  
Regards,
Nurit


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Rui Costa
Sent: Thursday, July 14, 2011 8:33 PM
To: David Allan I
Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: RE: [mpls] Last Call:
(Proactive Connectivity
Verification, Continuity Check and Remote Defectindication for MPLS
Transport Profile) to Proposed Standard

David,

T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the
simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the
work in T-MPLS or MPLS-TP would be rather pointless.
ITU-T was historically the right place to define such OAM. So, our
interest started with ITU-T's work in T-MPLS and not when IETF joined.


We value IETF's work, and in 2008, when the IETF rose doubts about
future interoperability between T-MPLS and MPLS/IP (and the "danger to
the internet"), even though all T-MPLS Recommendations were approved and
the OAM one was ready for approval, a decision was made to listen
carefully to MPLS/IP's top experts' input.


IETF's unilateral decision to select BFD was IMHO a surprise: being a
primary goal in T-MPLS, i'd assume OAM definition was ITU-T's
responsibility/expertise or at least a compromise between the 2 SDOs.
ITU-T's not just a boilerplate stamper.
Hearing that "the decision was expressed in mpls-tp-analysis draft" was
another surprise: among the possible ways, the document showed, IMHO,
1731 as the closest one to requirements.


We don't need a requirement to agree on reusing as most as possible MPLS
and PW: it's common sense. However, it can't distract us from primary
goals.


"The issue is not code point, which is the trivial part. It is reuse of
the majority of the implementation. Again, pretty basic."
In other words, the problem is not backwards compatibility, (ergo the
"danger to the internet" problem never really existed) but maintaining
particular deployed platforms. If we had to convert cars into planes, we
couldn't say "to reuse the implementation, we can't add wings": they
wouldn't fly.
I'm used to FW/HW development and i don't share your cost/simplicity
view. (Please check other LC responses on this particular point.) I know
field network support and think you'd change your opinion if you had to
work on 24h field network support.



I agree with you that other opinions exist, counting not only
manufacturers but also operators. On the operators that don't agree with
you are certainly clients of yours. It's none of my business that you
view their opinions as "grumblings", but that's far from describing the
polls' results in the Feb2011 WG3 and SG15 plenaries, showing a minority
sharing your view, and that, although those not subscribing it tolerate
its evolution, you don't theirs.
Operators and their clients are the ones that, at the end of the day,
pay for networks. From the above, it'll be IMHO impossible to understand
if these Recommendations don't take into account these "grumblers'"
view, other than the obsession of those insisting to sell swiss knifes
to those who just want sharp scalpels. Why don't we call that also "not
constructive"?
"[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and
more difficult to tell which is which.
[D:]That is because MPLS-TP is not a new techology, it is an addition to
the entire MPLS protocol suite."
Yes, i understand your view, David, but i'm sure you and i don't
subscribe this one:
"The creatures outside looked from pig to man, and from man to pig, and
from pig to man again; but already it was impossible to say which was
which".

Hope this helps. My comrade cents,
Rui



-Original Message-
From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: sexta-feira, 8 de Julho de 2011 17:13
To: Rui Costa; Stewart Bryant
Cc: erminio.ottone...@libero.it; m...@ietf.org; ietf@ietf.org;
IETF-Announce
Subject: RE: [mpls] Last Call: 
(Proactive Connectivity Verification, Continuity Check and Remote Defect
indication for MPLS Transport Profile) to Proposed Standard

Rui:

You wrote:

>Reading something, keeping it on record, without effect in the draft
and "ignoring comments" have IMHO similar outcomes. As author of the
draft you are free to do it. These standards have a great impact
>in our work, so i'm also free to write what i did.

Numerous comments did have effect on the draft and those that didn't
were either simply not actionable, were rhetorical or not constructive,
and a few had to be balanced against comments coming from the MPLS & BFD
WGs. I would translate "ingored" or "without effect" to "did not get
one'e way". In the standards process it happens.

>My technical concerns regarding this draft were expressed...
>...in the (ITU-T -> IETF, F

RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[Rui Costa]

David,

T-MPLS rose from MPLS/IP's OAM blanks. Our main interest on it is the 
simple/reliable OAM we had in SDH but lost in MPLS/IP. Otherwise, the work in 
T-MPLS or MPLS-TP would be rather pointless.
ITU-T was historically the right place to define such OAM. So, our interest 
started with ITU-T's work in T-MPLS and not when IETF joined.


We value IETF's work, and in 2008, when the IETF rose doubts about future 
interoperability between T-MPLS and MPLS/IP (and the "danger to the internet"), 
even though all T-MPLS Recommendations were approved and the OAM one was ready 
for approval, a decision was made to listen carefully to MPLS/IP's top experts' 
input.


IETF's unilateral decision to select BFD was IMHO a surprise: being a primary 
goal in T-MPLS, i'd assume OAM definition was ITU-T's responsibility/expertise 
or at least a compromise between the 2 SDOs. ITU-T's not just a boilerplate 
stamper.
Hearing that "the decision was expressed in mpls-tp-analysis draft" was another 
surprise: among the possible ways, the document showed, IMHO, 1731 as the 
closest one to requirements.


We don't need a requirement to agree on reusing as most as possible MPLS and 
PW: it's common sense. However, it can't distract us from primary goals.


"The issue is not code point, which is the trivial part. It is reuse of the 
majority of the implementation. Again, pretty basic."
In other words, the problem is not backwards compatibility, (ergo the "danger 
to the internet" problem never really existed) but maintaining particular 
deployed platforms. If we had to convert cars into planes, we couldn't say "to 
reuse the implementation, we can't add wings": they wouldn't fly.
I'm used to FW/HW development and i don't share your cost/simplicity view. 
(Please check other LC responses on this particular point.) I know field 
network support and think you'd change your opinion if you had to work on 24h 
field network support.



I agree with you that other opinions exist, counting not only manufacturers but 
also operators. On the operators that don't agree with you are certainly 
clients of yours. It's none of my business that you view their opinions as 
"grumblings", but that's far from describing the polls' results in the Feb2011 
WG3 and SG15 plenaries, showing a minority sharing your view, and that, 
although those not subscribing it tolerate its evolution, you don't theirs.
Operators and their clients are the ones that, at the end of the day, pay for 
networks. From the above, it'll be IMHO impossible to understand if these 
Recommendations don't take into account these "grumblers'" view, other than the 
obsession of those insisting to sell swiss knifes to those who just want sharp 
scalpels. Why don't we call that also "not constructive"?
"[R:] IMHO, between your MPLS-TP view and MPLS/IP, it becomes more and more 
difficult to tell which is which.
[D:]That is because MPLS-TP is not a new techology, it is an addition to the 
entire MPLS protocol suite."
Yes, i understand your view, David, but i'm sure you and i don't subscribe this 
one:
"The creatures outside looked from pig to man, and from man to pig, and from 
pig to man again; but already it was impossible to say which was which".

Hope this helps. My comrade cents,
Rui



-Original Message-
From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: sexta-feira, 8 de Julho de 2011 17:13
To: Rui Costa; Stewart Bryant
Cc: erminio.ottone...@libero.it; m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: RE: [mpls] Last Call:  (Proactive 
Connectivity Verification, Continuity Check and Remote Defect indication for 
MPLS Transport Profile) to Proposed Standard

Rui:

You wrote:

>Reading something, keeping it on record, without effect in the draft and 
>"ignoring comments" have IMHO similar outcomes. As author of the draft you are 
>free to do it. These standards have a great impact
>in our work, so i'm also free to write what i did.

Numerous comments did have effect on the draft and those that didn't were 
either simply not actionable, were rhetorical or not constructive, and a few 
had to be balanced against comments coming from the MPLS & BFD WGs. I would 
translate "ingored" or "without effect" to "did not get one'e way". In the 
standards process it happens.

>My technical concerns regarding this draft were expressed...
>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i believe);
>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary 
>meeting;

I and the WG don't really have access to private grumblings.

Lots of other opinions were expressed as well, and they did not all agree with 
you.

>Some:
>CC/CV
>I don't understand the need for 2 types of packets: a single type allows CC; 
>mismatching identifiers in the same CC packets allow CV.
>Besides adding complexity, we whether always activate both or potentiate 
>undetected mismerges.

OK, lets walk through this.

We want CV all the time so that any misconectivity can

Re: Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback

[Peter Saint-Andre]

Mark, I will work with the authors on proposed wording to describe the
context in which this technology is most applicable, and post again once
we've done that.

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. 
> 
> 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 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 Track as a general
>>> mechanism.
>>
>> How about publishing it on the standards track but not as a general
>> mechanism (i.e., why not clarify when it is and is not appropriate)?
>>
>> Clearly, both service providers (Google, Yahoo, etc.) and spec authors
>> (draft-hardjono-oauth-dynreg-00, draft-hardjono-oauth-umacore-00) have
>> found hostmeta somewhat useful in certain contexts.
>>
>> RFC 2026 says:
>>
>>   A Proposed Standard specification is generally stable, has resolved
>>   known design choices, is believed to be well-understood, has received
>>   significant community review, and appears to enjoy enough community
>>   interest to be considered valuable.
>>
>> and:
>>
>>   Usually, neither implementation nor operational experience is
>>   required for the designation of a specification as a Proposed
>>   Standard.  However, such experience is highly desirable, and will
>>   usually represent a strong argument in favor of a Proposed Standard
>>   designation.
>>
>> The spec seems to be stable at this point, it's received significant
>> review, people seem to understand what it does and how it works, it's
>> had both implementation and operational experience, and it appears to
>> enjoy enough community interest to be considered valuable in certain
>> contexts. I also think it has resolved the design choices and solved the
>> requirements that it set out to solve, although you might be right that
>> it doesn't solve all of the problems that a more generic metadata
>> framework would need to solve.
>>
>> As a result, it seems like a fine candidate for Proposed Standard, i.e.,
>> an entry-level document on the standards track that might be modified or
>> even retracted based on further experience.
>>
>>> Mostly, it's because I hasn't really seen much discussion of it as a
>>> general component of the Web / Internet architecture; AFAICT all of
>>> the interest in it and discussion of it has happened in more
>>> specialised / vertical places. 
>>
>> Again, perhaps we need to clarify that it is not necessarily a general
>> component of the web architecture, although it can be used to solve more
>> specific problems.
>>
>>> The issues below are my concerns;
>>> they're not insurmountable, but I would have expected to see some
>>> discussion of them to date on lists like this one and/or the TAG list
>>> for something that's to be an Internet Standard.
>>>
>>>
>>> * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe
>>> I'm just scarred by WS-*, but it seems very over-engineered for what
>>> it does. I understand that the communities had reasons for using it
>>> to leverage an existing user base for their specific user cases, but
>>> I don't see any reason to generalise such a beast into a generic
>>> mechanism.
>>
>> As discussed in responses to your message, XRD seems to have been an
>> appropriate tool for the job in this case. Whether XRD, too, is really a
>> general component of the web architecture is another question.
>>
>>> * Precedence -- In my experience one of the most difficult parts of a
>>> metadata framework like this is specifying the combination of
>>> metadata from multiple sources in a way that's usable, complete and
>>> clear. Hostmeta only briefly mentions precedence rules in the
>>> introduction.
>>
>> That could be something to work on if and when folks try to advance this
>> technology to the next maturity level (currently Draft Standard).
>>
>>> * Scope of hosts -- The document doesn't crisply define what a "host"
>>> is.
>>
>> This seems at least somewhat well-defined:
>>
>>   a "host" is not a single resource but the entity
>>   controlling the collection of resources identified by Uniform
>>   Resource Identifiers (URI) with a common URI host [RFC3986].
>>
>> That is, it references Section 3.2.2 of RFC 3986, which defines "host"
>> with some precision (albeit perhaps not "crisply").
>>
>>> * Context of metadata -- I've become convinced that the most
>>> successful uses of .well-known URIs are those that have commonality
>>> of use; i.e., it makes sense to define a .well-known URI when most of
>>> the data returned is applicable to a particular use case or set of
>>> use cases. This is why robots.txt works well, as do most other
>>> currently-deployed examples of well-known URIs

Re: Confidentiality notices on email messages

[Marc Petit-Huguenin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/14/2011 08:28 AM, Alessandro Vesely wrote:
> On 14/Jul/11 03:48, John Levine 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 respect the wishes of the sender.
>>
>> That respect would of course be demonstrated by rejecting or
>> discarding the mail unread, to avoid any possibility that it could
>> fall into the wrong hands.
> 
> Yes, with the possible exception of recipients deploying a Treacherous
> Computing environment that includes checks against forwarding or
> replying with non fair use quotations of confidential messages.
> 
>> PS: Perhaps I should propose a revised RFC 5617 adding dkim=confidential.
> 
> One can sign the "Sensitivity" header field defined by RFC 2156.  It
> can have the values "Personal" / "Private" / "Company-Confidential".
> 
> However, I received some messages bearing a confidentiality notice but
> missing this field entirely.  Even the TC system above could hardly
> cope with such inconsistent settings.

1. If an email received contains a Sensivity header with Confidential, Private
or Personal, the email is rejected.

2. Else, with techniques similar to spam filtering, a process can then test if
the email may contain a legal notice (perhaps Spamassassin can be configured to
do this - I am not a specialist).  If such notice is detected, and there is no
Sensivity header the email is bounced back with a text similar to this:

"We automatically detected that your email may contain a legal notice, but we
have no way to be sure that this notice is compliant with our rules, but we
cannot take the legal risk to accept it against the wishes of your employer.
Please contact your IT department and ask them to add a Sensivity header to the
emails sent by your organization, which should be even easier than adding the
legal notice."

3. Else, if a notice is detected and there is a Sensivity=public header, then
the email is accepted.

4. Else, if no notice is detected, the email is accepted.


> Do notices still retain any
> legal value in such cases?

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk4fHPUACgkQ9RoMZyVa61f1HwCcDCWWIade84CPrOGglYUOS5Jk
UPMAn0eETDcMfjPq6do1Jb92eWGud+ls
=dlvr
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Will McAfee]

They don't have legal value, period.

Sent from my iPhone

On Jul 14, 2011, at 11:28 AM, Alessandro Vesely  wrote:

> On 14/Jul/11 03:48, John Levine 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 respect the wishes of the sender.
>> 
>> That respect would of course be demonstrated by rejecting or
>> discarding the mail unread, to avoid any possibility that it could
>> fall into the wrong hands.
> 
> Yes, with the possible exception of recipients deploying a Treacherous
> Computing environment that includes checks against forwarding or
> replying with non fair use quotations of confidential messages.
> 
>> PS: Perhaps I should propose a revised RFC 5617 adding dkim=confidential.
> 
> One can sign the "Sensitivity" header field defined by RFC 2156.  It
> can have the values "Personal" / "Private" / "Company-Confidential".
> 
> However, I received some messages bearing a confidentiality notice but
> missing this field entirely.  Even the TC system above could hardly
> cope with such inconsistent settings.  Do notices still retain any
> legal value in such cases?
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

R: RE: [mpls] R: RE: R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed

[erminio.ottone...@libero.it]

The JWT report is aligned with my statement.

The decision at IETF75 has been taken by the MPLS WG after the JWT and has 
never been endorsed by ITU-T (Huub is NOT ITU-T and, as far as I understood, he 
later removed his name because the other editors of the OAM Analysis draft were 
not considering his input to the document).

The BFD-based solution accepted by IETF75 for pro-active CC/CV/RDI was 
completely different (and technically much superior) than the one described by 
this draft.

Accepting a solution that meets the requirements does not mean signing a blank 
cheque that whichever changes is done is acceptable regarless whether it meets 
or not the requirements.

>Messaggio originale
>Da: jdr...@juniper.net
>Data: 13-lug-2011 22.46
>A: "erminio.ottone...@libero.it", "david.i.
al...@ericsson.com", "rco...@ptinovacao.pt"
, "ietf@ietf.org", "IETF-Announce"
>Cc: "m...@ietf.org"
>Ogg: RE: [mpls] R: RE: R: Re:  LastCall:   
> (Proactive  ConnectivityVerification,   Continuity Check and 
Remote 
Defect  indication  for MPLSTransport   Profile) to Proposed 
Standard
>
>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 transport network is an MPLS 
application that intrinsically requires a different OAM solution is simply a 
lame ex post facto attempt to justify the ITU's abrogation of the agreement 
with the IETF (TD07 (WP3/SG15) from December 2008 sourced by SG15):
>
>"The ITU-T accepts these recommendations and states that any extensions to 
MPLS technology will be progressed via the IETF standards process using the 
procedures defined in RFC 4929 (Change Process for Multiprotocol Label 
Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures).  
Experts from the ITU-T will assist the IETF in the development of RFCs that 
describe the transport extensions by providing input to and review of the 
drafts as they are progressed via the IETF standards process.. The ITU-T will 
develop new or revised Recommendations that will allow IETF MPLS-TP to be 
integrated into the transport network including integration with the existing 
equipment, and operations infrastructure.  These Recommendations will make 
normative references to the base IETF MPLS-TP technology and will be developed 
with input from and review by experts from the IETF to ensure consistency with 
MPLS-TP...
>
>The ITU-T has accepted the proposals from the JWT and we look forward to 
continuing the cooperative development of IETF MPLS to address the needs of the 
transport network. We also believe that this resolution will fulfil the mutual 
goal of improve the functionality of the internet and transport networks and 
guaranteeing complete interoperability and architectural soundness."
>
>Thanks,
>
>John
>
>Sent from my iPhone
>
>> -Original Message-
>> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
>> erminio.ottone...@libero.it
>> Sent: Wednesday, July 13, 2011 1:27 PM
>> To: david.i.al...@ericsson.com; rco...@ptinovacao.pt; ietf@ietf.org;
>> IETF-Announce
>> Cc: m...@ietf.org
>> Subject: [mpls] R: RE: R: Re: Last Call: > 05.txt> (Proactive Connectivity Verification, Continuity Check and
>> Remote Defect indication for MPLS Transport Profile) to Proposed
>> Standard
>> 
>> >However this is a consequence of adapting an existing technology to a
>> new
>> application. I do not see any way around that. And the entire joint
>> project was
>> based on the premise of engineering re-use not greenfield design. That
>> is what
>> it said on the tin up front, and IMO why when the IETF started down
>> this path
>> packet transport transitioned from being a minority sport to
>> mainstream, so it
>> is a bit late to cry foul
>> 
>> This is not what the IETF has committed to deliver to ITU-T and in fact
>> slide
>> 44 postpones to the OAM design phase "decide whether LSP-Ping or BFD
>> can or
>> should be tweaked or not" and slide 46 reckons "many options including
>> non IP
>> BFD is an option encapsulation of Y.1731 PDU"
>> 
>> It seems to me after having read the draft and followed this very long
>> thread
>> that tweaking BFD is not the right approach to meet ITU-T requirements
>> so it
>> would be worth evaluating the other alternative considered viable by
>> the JWT
>> which is encapulating Y.1731 PDUs.
>> 
>> >Messaggio originale
>> >Da: david.i.al...@ericsson.com
>> >Data: 6-lug-2011 20.24
>> >A: "erminio.ottone...@libero.it",
>> "rco...@ptinovacao.pt",
>> "ietf@ietf.org",
>> "IETF-Announce"
>> >Cc: "m...@ietf.org"
>> >Ogg: RE: [mpls] R: Re: Last Call:   > 05.txt>
>> (Proactive   ConnectivityVerification,   Continuity Check and
>> Remote Defect
>> 

Re: Confidentiality notices on email messages

[Alessandro Vesely]

On 14/Jul/11 03:48, John Levine 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 respect the wishes of the sender.
> 
> That respect would of course be demonstrated by rejecting or
> discarding the mail unread, to avoid any possibility that it could
> fall into the wrong hands.

Yes, with the possible exception of recipients deploying a Treacherous
Computing environment that includes checks against forwarding or
replying with non fair use quotations of confidential messages.

> PS: Perhaps I should propose a revised RFC 5617 adding dkim=confidential.

One can sign the "Sensitivity" header field defined by RFC 2156.  It
can have the values "Personal" / "Private" / "Company-Confidential".

However, I received some messages bearing a confidentiality notice but
missing this field entirely.  Even the TC system above could hardly
cope with such inconsistent settings.  Do notices still retain any
legal value in such cases?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Joel Jaeggli]

On Jul 14, 2011, at 6:24 AM, Dave CROCKER wrote:

> 
> 
> On 7/12/2011 2:36 PM, Jorge Contreras wrote:
>> 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 subject to any privilege, can be disregarded for all 
>> purposes,
>> and will be of no force or effect."
> 
> 
> Jorge,
> 
> It's excellent that the issue was covered in the RFC.
> 
> My question is how the contents of that RFC can be binding on random IETF 
> participants?

Everyone on this list has be asked to and has accepted the note well.

> I doubt many folk even know about the item, even if they know about the RFC 
> and I don't see how they have agreed to those terms.

http://www.ietf.org/about/note-well.html

> Has the force of this been tested?  That is, when there is a conflict between 
> the conditions imposed by one of these email attachments and the terms in RFC 
> 5378, is there equivalent legal precedent for the RFC to win?
> 
> Thanks.
> 
> d/
> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re[2]: [mpls] Last Call:(Proactive Connecti

[hideki.endo.es]

Sorry for resending.

The changes in this version have massive impact for CC/CV/RDI implementation.
We, venders, have kept making efforts on interoperability test again and again.
These changes spoil this effort.

Especially, revival of Poll/Final sequence doesn't make sense.
Originally, in my understanding, Poll/Final sequence was excluded from this 
draft
to avoid making HW implementation difficult. 

Even though it was difficult to change CC interval arbitrary, 
the problem should be solved by defining how to transit DOWN/INIT state to UP 
state.

The direction which reached consensus once should NOT be changed easily
in order to respond to the market requirements.

IMO, such major changes should NOT be added right before becoming RFC.

I found at least four major/minor changes as follows;
1)Revival of Poll/Final sequence
2)Change of MEP ID formats
3)Change of Diag. Code
4)Change of CV interleaved definition

BR,
Hideki


>
>>
>>The IESG has received a request from the Multiprotocol Label Switching WG
>>(mpls) to consider the following document:
>>- 'Proactive Connectivity Verification, Continuity Check and Remote
>>   Defect indication for MPLS Transport Profile'
>>   as a Proposed Standard
>>
>>The IESG plans to make a decision in the next few weeks, and solicits
>>final comments on this action. Please send substantive comments to the
>>ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be
>>sent to i...@ietf.org instead. In either case, please retain the
>>beginning of the Subject line to allow automated sorting.
>>
>>Abstract
>>
>>   Continuity Check, Proactive Connectivity Verification and Remote
>>   Defect Indication functionalities are required for MPLS-TP OAM.
>>
>>   Continuity Check monitors the integrity of the continuity of the
>>   label switched path for any loss of continuity defect. Connectivity
>>   verification monitors the integrity of the routing of the label
>>   switched path between sink and source for any connectivity issues.
>>   Remote defect indication enables an End Point to report, to its
>>   associated End Point, a fault or defect condition that it detects on
>>   a pseudo wire, label switched path or Section.
>>
>>   This document specifies methods for proactive continuity check,
>>   continuity verification, and remote defect indication for MPLS-TP
>>   label switched paths, pseudo wires and Sections using Bidirectional
>>   Forwarding Detection.
>>
>>
>>The file can be obtained via
>>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/
>>
>>IESG discussion can be tracked via
>>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/
>>
>>
>>No IPR declarations have been submitted directly on this I-D.
>>___
>>mpls mailing list
>>m...@ietf.org
>>https://www.ietf.org/mailman/listinfo/mpls
>>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mpls] R: RE: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[Greg Mirsky]

Dear Erminio,
I'd point that the scope of G.8113.1, a.k.a G.tpoam in regard to CCM is even
more narrow then of the document being discussed. The G.8113.1 addresses
only bi-directional co-routed LSP and has no model to handle bi-directional
associated LSP in independent mode. And unidirectional p2p and p2mp LSPs are
not addressed by the current revision of the G.8113.1.
Can all these out-of-scope constructs be used to conclude that G.8113.1 is
not capable to solve these issues? I don't think so. Solutions are not
readily available, that's all.

Regards,
Greg

On Wed, Jul 13, 2011 at 1:38 PM, erminio.ottone...@libero.it <
erminio.ottone...@libero.it> wrote:

> >I would not go so far as to say "similar to 1731", there is actually a lot
> of
> difference under the hood. As for uni-directional BFD, that is a BFD WG
> problem
> at the moment.
>
> The fact that the BFD WG has not defined a solution for unidirectional p2p
> and
> p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP
> nor
> does resolve the technical issue that have been raised.
>
> >Messaggio originale
> >Da: david.i.al...@ericsson.com
> >Data: 8-lug-2011 18.13
> >A: "Rui Costa", "Stewart Bryant" >
> >Cc: "erminio.ottone...@libero.it",
> "mpls@ietf.
> org", "ietf@ietf.org", "IETF-Announce" annou...@ietf.org>
> >Ogg: RE: [mpls] Last Call: 
> (Proactive  Connectivity Verification, Continuity Check and Remote
> Defect
> indication for MPLS Transport   Profile) to Proposed Standard
> >
> >Rui:
> >
> >You wrote:
> >
> >>Reading something, keeping it on record, without effect in the draft and
> "ignoring comments" have IMHO similar outcomes. As author of the draft you
> are
> free to do it. These standards have a great impact
> >>in our work, so i'm also free to write what i did.
> >
> >Numerous comments did have effect on the draft and those that didn't were
> either simply not actionable, were rhetorical or not constructive, and a
> few
> had to be balanced against comments coming from the MPLS & BFD WGs. I would
> translate "ingored" or "without effect" to "did not get one'e way". In the
> standards process it happens.
> >
> >Meanwhile as an editor of the document, I'll take the liberty of
> responding
> to some of the points you raise...
> >
> >>My technical concerns regarding this draft were expressed...
> >>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i
> believe);
> >>...in operators' meetings' that took place during ITU-T's Feb/2011
> plenary
> meeting;
> >
> >I and the WG don't really have access to private grumblings.
> >
> >>...in a comparison session that took place during that same ITU-T
> meeting.
> >
> >Lots of other opinions were expressed as well, and they did not all agree
> with you.
> >
> >>Some:
> >>CC/CV
> >>I don't understand the need for 2 types of packets: a single type allows
> CC;
> mismatching identifiers in the same CC packets allow CV.
> >>Besides adding complexity, we whether always activate both or potentiate
> undetected mismerges.
> >
> >OK, lets walk through this.
> >
> >We want CV all the time so that any misconectivity can be detected, but on
> the list it was expressed that the group did not want the overhead of
> processing the source MEP TLV in every packet in order to achieve this. We
> could carry it in every packet and have the receiver simply ignore most of
> them, but then that would make the defect entry criteria compeltely random
> and
> the exit criteria unreliable as well, not really a good design. Hence they
> are
> separated using different ACH code points and the receiver is obliged to
> process every source MEP TLV it receives. I hope this is clear.
> >
> >>(BTW: can't understand how we propose one ACH codepoint to CC, another
> for
> CV, [counting other drafts, another for frame loss ...] but don't consider
> assigning 1 single ACH protocol identifier codepoint >as requested by
> ITU-T)
> >
> >Because that puts you into two protocol ID demultiplexing steps per OAM
> PDU
> recevied to determine the intended function. Hence COSTS MORE. That is
> pretty
> basic...
> >
> >> Uni P2P / P2MP
> >> I can't see how BFD will support unidir and hence P2MP other than...
> >> ...eliminating the session "state variable" (down, init, up), aiming
> just
> the state variables we really need, bringing us to something similar to
> 1731,
> eventually with other bits on the wire or...
> >> ...using IP to create the reverse way, which we cannot assume per
> requirements;
> >> Will we create a complete different tool for that?
> >> (BFD's B="bidirectional")
> >
> >I would not go so far as to say "similar to 1731", there is actually a lot
> of
> difference under the hood. As for uni-directional BFD, that is a BFD WG
> problem
> at the moment.
> >
> >> Provisioning list
> >> This is an MPLS profile/subset (and i heard) achievable through a
> particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus
> on
> that pr

Re: [mpls] R: RE: R: Re: LastCall: (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan

[Greg Mirsky]

Dear Erminio,
even though I'm not an operator but I think that you've went bit too far in
your first generalization.
"Every generalization is wrong, including this one"

Regards,
Greg

On Wed, Jul 13, 2011 at 1:32 PM, erminio.ottone...@libero.it <
erminio.ottone...@libero.it> wrote:

> The technical concern raised during the WG poll has not been resolved so
> the
> history definetely matters.
>
> Quoting RFC5921:
>
>   There are thus two objectives for MPLS-TP:
>
>   1.  To enable MPLS to be deployed in a transport network and operated
>   in a similar manner to existing transport technologies.
>
>   2.  To enable MPLS to support packet transport services with a
>   similar degree of predictability to that found in existing
>   transport networks.
>
> Based on the extensive comments provided by transport operators and ITU-T
> community, the solution in this draft is useless in case 1.
>
> The fact that the solution in this draft is not backward compatible with
> existing IP/MPLS BFD implementations means that this solution is also
> uselesee
> in case 2.
>
> Are there other undocumented use cases for MPLS-TP deployments?
>
> >Messaggio originale
> >Da: nurit.sprec...@nsn.com
> >Data: 7-lug-2011 11.59
> >A: , ,  >,
> "IETF-Announce"
> >Cc: 
> >Ogg: RE: [mpls] R: Re: LastCall:
> 
> (Proactive  ConnectivityVerification,Continuity Check and Remote
> Defect
> indicationfor   MPLSTransport   Profile) to Proposed Standard
> >
> >Erminio,
> >I do not think the history is relevant for this specific discussion...
> >Also I find it inappropriate to give statements with no justifications
> >behind.
> >You say: "the solution in this draft is useless for many MPLS-TP
> >deployments.".  in order to seriously consider your comment, you have to
> >show why it is useless and which requirements are not satisfied.
> >Otherwise you cannot expect anyone to refer to your point.
> >Best regards,
> >Nurit
> >
> >P.s. did you mean that the document is useless to available non-standard
> >deployments, e.g. T-MPLS?
> >
> >
>
>
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Stan

[David Allan I]

HI Erminio:

The comments that were raised during the day long discussion with the editors 
at the SG15 plenary resulted in those comments appearing in the liasion IMO in 
an actionable form and resulted in a constructive outcome. I enjoyed that level 
of cooperation.

The comments that were punted over the wall with no discussion (depsite 
requests to allocate meeting time to do so) in some cases were sufficiently 
vague as to have no constructive value or not have a recognizable issue to be 
addressed.

A request to have the commenters identified in the liaison so that comments 
that were unclear could be followed up upon by the editors was refused. 
Apparently that is not done and I would go so far as to suggest that blanket of 
anonymity diminished the quality of the liaison.  The result of this process 
was that the only recourse to go "what does this mean?" was a complete liaison 
cycle. For some comments, stomaching a multi-month delay to clarify what the 
actual issue was that resulted in a comment like "describe the start-up 
procedure" was not reasonable, especially given SG15s continual complaint on 
how slow the IETF was. Such comments had to be weighed against the nature of 
comments from the larger reviewing community that seemed to have no issue with 
the completeness of the document content and perhaps had actually read it and 
the supporting documents.

I'll call out an example: a comment that appeared more than once in the liaison 
was "clarify the raising/clearing of defects as well as any consequent actions" 
which I can only interpret as section 3.7 of the document not having been read. 
E.g. the TOC is:

3.7.1. Session initiation and Modification  13
3.7.2. Defect entry criteria13
3.7.3. Defect entry consequent action   14
3.7.4. Defect exit criteria 15
3.7.5. State machines   15

...and if there was a deficiency in the descriptions it was not identified, and 
we're not mind readers.

So that is both the history and why some comments were rejected. If you can 
suggest a constructive way to proceed that is not simply a waste of everyone's 
time, I'll listen..

Cheers
Dave








-Original Message-
From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] 
Sent: Wednesday, July 13, 2011 1:28 PM
To: David Allan I; l...@pi.nu; Rui Costa
Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce
Subject: R: RE: [mpls] R: Re: Last Call:  
(Proactive Connectivity Verification, Continuity Check and Remote Defect 
indication for MPLS Transport Profile) to Proposed Standard

Do you mean that ITU-T comments were discussed and resolution agreed during the 
ITU-T meeting?

If this is the case, why the LS just provides the comments and not the agreed 
resolution?

Why some ITU-T comments have been then rejected?

>Messaggio originale
>Da: david.i.al...@ericsson.com
>Data: 6-lug-2011 19.35
>A: "erminio.ottone...@libero.it", "l...@pi.nu"
, "Rui Costa"
>Cc: "m...@ietf.org", "ietf@ietf.org", 
>"IETF-
Announce"
>Ogg: RE: [mpls] R: Re: Last Call:  
> 
(Proactive Connectivity Verification, Continuity Check and Remote Defect 
indication for  MPLSTransport   Profile) to Proposed Standard
>
>Hi Erminio:
>
>Two of the three document editors were present at SG15 plenary in 
>February
where the comments originated. The revised meeting schedule resulted in a day 
spent going through the document with the editors. IMO there were lots of 
discussion and legitimate issues with the document identified and corrected so 
it was a useful session. The liaison of same was in many ways *after the fact*.
>
>Cheers
>Dave
>


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RFC Series Editor Search Announcement

[RSOC Chair]

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 and 
policy development responsibilities.

The overall leadership and supervision of RFC Editor function is the 
responsibility of the RFC Series Editor. 
The RSE is a senior professional who must be skilled in leading, managing and 
enhancing a critical, 
multi-vendor, global information service.   

The following qualifications are desired: 

1.  Leadership and management experience.  In particular, demonstrated 
experience in strategic 
planning and the management of entire operations.  Experience that can 
be applied to fulfill 
the tasks and responsibilities described in RFC Editor Model (version 
2) 
.
2.  Excellent written and verbal communication skills in English and 
technical terminology related 
to the Internet a must; additional languages a plus.
3.  Experience with editorial processes. 
4.  Familiar with a wide range of Internet technologies.
5.  An ability to develop a solid understanding of the IETF, its culture 
and RFC process.
6.  Ability to work independently, via email and teleconf, with strong time 
management skills.
7.  Willingness and ability to travel as required.
8.  Capable of effectively functioning in a multi-actor and matrixed 
environment with divided 
authority and responsibility; ability to work with clarity and 
flexibility with different constituencies.
9.  Experience as an RFC author desired.

More information about the position can be found at 
.

The RSE reports to the RFC Series Oversight Committee (RSOC).

Expressions of interest in the position, CV (including employment history), 
compensation 
requirements, and references should be sent to the RSOC search committee at 
rse-sea...@iab.org  
Applications will be kept confidential.  The application period is open until 
the position is filled.

Questions are to be addressed to rse-sea...@iab.org. 

The RSOC will interview interested parties at the IETF meeting in Quebec City 
that begins 
July 24, 2011.

Fred Baker
Chair
RFC Series Oversight Committee
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

R: [mpls] R: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[erminio.ottone...@libero.it]

It looks like this draft does not define a "single" solution for CC, CV and RDI 
function

>Messaggio originale
>Da: alessandro.dalessan...@telecomitalia.it
>Data: 13-lug-2011 15.02
>A: "IETF-Announce"
>Cc: "m...@ietf.org", "ietf@ietf.org"
>Ogg: [mpls] R: Last Call:   
(Proactive Connectivity Verification, Continuity Check and Remote Defect 
indication for  MPLSTransport   Profile) to Proposed Standard
>
>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) I have the following 
comments on this version:
>
>1. it is not clear the BFD's scope
>Sect. 1: PW, LSP, SPME
>Sect. 1: LSP
>Sect 3: LSP
>Sect 3.1:LSP, PW
>Sect 3.3: PW, LSP, SPME, Section
>Sect 3.7: LSP
>
>2. encapsulation
>Sect 1: supported encapsulation GAL/GACh, VCCV, UDP/IP: can be 
expressed a preference (MUST/MAY) for Transport Profile applications for 
interoperability issues? I would avoid single vendor networks coming from too 
many options.
>
>3. diagnostic code 5
>Could you clarify what is the BFD state machine behavior 
receiving/transmitting a Diagn Code=5
>
>4. detection time
>Sect 3.2: I expect it is that one defined in RFC5884 i.e. detect Mult 
x greater (bfd.requiredminrxinterval, last received desired min tx interval). 
What "interval" means is not clear
>
>5. session periodicity
>Sec 3.3 Should be clarified being not defined in RFC5880
>
>6. detection of loss of continuity
>Sect 3.3 can CV packet  sent on the wire replace CC packet (for LOC 
purpose on the far end)?
>
>7. CV vs CC packets
>Sect 3.6 Generally speaking, how should the received CV packet's 
fields be managed with respect of the BFD state machine/BFD states? (beyond 
what is specified in such paragraph limited to P/F and Sta).
>
>8. encoding
>Sect 3.5: could you clarify what " A BFD session will only use one 
encoding of the Source ID TLV" means?
>
>9. editorial
>Source ID TLV, MEP source ID TLV, Source MEP TLV should be aligned
>
>10. terminology
>Wrt sect 3.6 I would ask a clarification about the terminology where 
I found
>a- "A BFD session corresponds to a CC and proactive CV OAM instance"
>b- " A BFD session is enabled when the CC and proactive CV 
functionality is enabled"
>c- " When the CC and proactive CV functionality is disabled ..., the 
BFD session transitions to the ADMIN DOWN State and the BFD session ends"
>In the ADMIN DOWN state I understood I can have BFD control 
packet exchange between the end points. Is it consistent with CC/CV 
functionality disabled?
>11. code points
>Code points are not specified in section 3.1 as stated
>
>12. BFD fixed rate
>Sect 3.7 " This rate is a fixed value common for both directions of 
MEG for the lifetime of the MEG". Is this statement implying that MEG must be 
destroyed to be able to change the BFD rate? Should not be limited to the BFD 
session lifetime (to be clarified what it means... because moving to ADMIN DOWN 
state both ends could not be enough)
>
>13. two BFD modes
>Sect 3.7 " Two independent BFD sessions are used for independent 
operation". In my opinion, this approach still remain a big limitation in BFD 
usage.
>Is it implementation specific the way the two ends distinguish 
between the two BFD modes?
>
>14. bfd.RemoteDiscr
>Sect 3.7 " In coordinated mode, an implementation SHOULD NOT reset 
bfd.RemoteDiscr until it is exiting the DOWN state"
>Is it a deviation from BFD as specified in RFC 5880? If it is, could 
you clarified the reason for that?
>
>15. bfd.RemoteDiscr
>Sect 3.7 Could you clarify the reasons behind different treatments 
for bfd.RemoteDiscr in coordinated mode and independent mode?
>
>16. overall operation
>Sect 3.7 "Overall operation is as specified in [4] and augmented for 
MPLS in[8]"
>Are you sure that it can be generalized in that way? Should not be 
the case to specify more in details what applies and what do not apply?
>
>17. IP-based BFD
>Sect 3.1  IP-based BFD can carry out CV functionality only if IP SA 
is public
>
>18. CV during transient states
>Sect 3.2 for clarification: at start-up, CC are sent one per second. 
CV are sent in addition to CC (so we have two BFD packets per second)?
>
>19. misconnections
>Sect 3.7.3 sect 3.7.3 states a misconnection bring BFD session to 
DOWN whilst it is not clear if sect 3.7.5 state that misconnection do not 
impact on BFD state transition
>
>20. encapsulation modes
>Sect 4: if I understood well, there are 4 encapusulations and modes 
for BFD: UDP/IP/LSP; CC mode in G-ACh; UPD/IP 

R: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[erminio.ottone...@libero.it]

>> Backwards compatibility
>> This was the main argument risen to ground MPLS-TP OAM on BFD. It's not a 
better argument than grounding MPLS-TP OAM on 1731 due to its ETH deployment 
plus coherence with SDH, OTN, as defended by ITU-T.
>> For reasons like the above, however, MPLS-TP BFD won't be backwards 
compatible with previous BFD (even considering just CC/CV). They don't even 
share the same codepoint.
>
>The issue is not code point, which is the trivial part. It is reuse of the 
majority of the implementation. Again, pretty basic.
>

I disagree. From a backward compatibility perspecting the codepoint is very 
relevant. An existing implementation does not reckon the new encapsulation: the 
only way to deploy this solution in a backward compatible manner is by 
upgrading all the IP/MPLS nodes that have been deployed up to so far.

I think that the "reuse of the majority of the implementation" is actually the 
issue. Those implementations do not have the capabilities required to be 
deployed in a transport network. 

Developing a non-transport capable standard will not make these boxes 
transport capable but it would just make the standard useless for a transport 
environment.

>Messaggio originale
>Da: david.i.al...@ericsson.com
>Data: 8-lug-2011 18.13
>A: "Rui Costa", "Stewart Bryant"
>Cc: "erminio.ottone...@libero.it", "mpls@ietf.
org", "ietf@ietf.org", "IETF-Announce"
>Ogg: RE: [mpls] Last Call:  
(Proactive  Connectivity Verification, Continuity Check and Remote Defect   
indication for MPLS Transport   Profile) to Proposed Standard
>
>Rui:
>
>You wrote:
>
>>Reading something, keeping it on record, without effect in the draft and 
"ignoring comments" have IMHO similar outcomes. As author of the draft you are 
free to do it. These standards have a great impact
>>in our work, so i'm also free to write what i did.
>
>Numerous comments did have effect on the draft and those that didn't were 
either simply not actionable, were rhetorical or not constructive, and a few 
had to be balanced against comments coming from the MPLS & BFD WGs. I would 
translate "ingored" or "without effect" to "did not get one'e way". In the 
standards process it happens.
>
>Meanwhile as an editor of the document, I'll take the liberty of responding 
to some of the points you raise...
>
>>My technical concerns regarding this draft were expressed...
>>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i 
believe);
>>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary 
meeting;
>
>I and the WG don't really have access to private grumblings.
>
>>...in a comparison session that took place during that same ITU-T meeting.
>
>Lots of other opinions were expressed as well, and they did not all agree 
with you.
>
>>Some:
>>CC/CV
>>I don't understand the need for 2 types of packets: a single type allows CC; 
mismatching identifiers in the same CC packets allow CV.
>>Besides adding complexity, we whether always activate both or potentiate 
undetected mismerges.
>
>OK, lets walk through this.
>
>We want CV all the time so that any misconectivity can be detected, but on 
the list it was expressed that the group did not want the overhead of 
processing the source MEP TLV in every packet in order to achieve this. We 
could carry it in every packet and have the receiver simply ignore most of 
them, but then that would make the defect entry criteria compeltely random and 
the exit criteria unreliable as well, not really a good design. Hence they are 
separated using different ACH code points and the receiver is obliged to 
process every source MEP TLV it receives. I hope this is clear.
>
>>(BTW: can't understand how we propose one ACH codepoint to CC, another for 
CV, [counting other drafts, another for frame loss ...] but don't consider 
assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T)
>
>Because that puts you into two protocol ID demultiplexing steps per OAM PDU 
recevied to determine the intended function. Hence COSTS MORE. That is pretty 
basic...
>
>> Uni P2P / P2MP
>> I can't see how BFD will support unidir and hence P2MP other than...
>> ...eliminating the session "state variable" (down, init, up), aiming just 
the state variables we really need, bringing us to something similar to 1731, 
eventually with other bits on the wire or...
>> ...using IP to create the reverse way, which we cannot assume per 
requirements;
>> Will we create a complete different tool for that?
>> (BFD's B="bidirectional")
>
>I would not go so far as to say "similar to 1731", there is actually a lot of 
difference under the hood. As for uni-directional BFD, that is a BFD WG problem 
at the moment.
>
>> Provisioning list
>> This is an MPLS profile/subset (and i heard) achievable through a 
particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on 
that profile/configuration. However, i keep seeing
>> references f.i. to IP enca

R: RE: [mpls] Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

[erminio.ottone...@libero.it]

>I would not go so far as to say "similar to 1731", there is actually a lot of 
difference under the hood. As for uni-directional BFD, that is a BFD WG problem 
at the moment.

The fact that the BFD WG has not defined a solution for unidirectional p2p and 
p2mp transport paths does not make BFD a suitable OAM protocol for MPLS-TP nor 
does resolve the technical issue that have been raised.

>Messaggio originale
>Da: david.i.al...@ericsson.com
>Data: 8-lug-2011 18.13
>A: "Rui Costa", "Stewart Bryant"
>Cc: "erminio.ottone...@libero.it", "mpls@ietf.
org", "ietf@ietf.org", "IETF-Announce"
>Ogg: RE: [mpls] Last Call:  
(Proactive  Connectivity Verification, Continuity Check and Remote Defect   
indication for MPLS Transport   Profile) to Proposed Standard
>
>Rui:
>
>You wrote:
>
>>Reading something, keeping it on record, without effect in the draft and 
"ignoring comments" have IMHO similar outcomes. As author of the draft you are 
free to do it. These standards have a great impact
>>in our work, so i'm also free to write what i did.
>
>Numerous comments did have effect on the draft and those that didn't were 
either simply not actionable, were rhetorical or not constructive, and a few 
had to be balanced against comments coming from the MPLS & BFD WGs. I would 
translate "ingored" or "without effect" to "did not get one'e way". In the 
standards process it happens.
>
>Meanwhile as an editor of the document, I'll take the liberty of responding 
to some of the points you raise...
>
>>My technical concerns regarding this draft were expressed...
>>...in the (ITU-T -> IETF, Feb/2011) liaison regarding it (LS281, i 
believe);
>>...in operators' meetings' that took place during ITU-T's Feb/2011 plenary 
meeting;
>
>I and the WG don't really have access to private grumblings.
>
>>...in a comparison session that took place during that same ITU-T meeting.
>
>Lots of other opinions were expressed as well, and they did not all agree 
with you.
>
>>Some:
>>CC/CV
>>I don't understand the need for 2 types of packets: a single type allows CC; 
mismatching identifiers in the same CC packets allow CV.
>>Besides adding complexity, we whether always activate both or potentiate 
undetected mismerges.
>
>OK, lets walk through this.
>
>We want CV all the time so that any misconectivity can be detected, but on 
the list it was expressed that the group did not want the overhead of 
processing the source MEP TLV in every packet in order to achieve this. We 
could carry it in every packet and have the receiver simply ignore most of 
them, but then that would make the defect entry criteria compeltely random and 
the exit criteria unreliable as well, not really a good design. Hence they are 
separated using different ACH code points and the receiver is obliged to 
process every source MEP TLV it receives. I hope this is clear.
>
>>(BTW: can't understand how we propose one ACH codepoint to CC, another for 
CV, [counting other drafts, another for frame loss ...] but don't consider 
assigning 1 single ACH protocol identifier codepoint >as requested by ITU-T)
>
>Because that puts you into two protocol ID demultiplexing steps per OAM PDU 
recevied to determine the intended function. Hence COSTS MORE. That is pretty 
basic...
>
>> Uni P2P / P2MP
>> I can't see how BFD will support unidir and hence P2MP other than...
>> ...eliminating the session "state variable" (down, init, up), aiming just 
the state variables we really need, bringing us to something similar to 1731, 
eventually with other bits on the wire or...
>> ...using IP to create the reverse way, which we cannot assume per 
requirements;
>> Will we create a complete different tool for that?
>> (BFD's B="bidirectional")
>
>I would not go so far as to say "similar to 1731", there is actually a lot of 
difference under the hood. As for uni-directional BFD, that is a BFD WG problem 
at the moment.
>
>> Provisioning list
>> This is an MPLS profile/subset (and i heard) achievable through a 
particular configuration. So, i expect each draft-ietf-mpls-TP-* to focus on 
that profile/configuration. However, i keep seeing
>> references f.i. to IP encapsulations unexpected under TP's OAM.
>> I don't thus understand what the aim is: do we expect this in TP, are we 
talking about MPLS in general?... The TP profile is never quite delimited.
>> Does chapter 4 contain ALL the configurable parameters list agreed to 
provide in the comparison session?
>
>It should. As for encapsulations, unless TP is in a complete island not 
connected to anything (which as a network is rather useless) it will be 
expected to interoperate with the rest of the MPLS architecture, and the stated 
intention of tool development was that what resulted was applicable to the 
broader MPLS architecture. Which means backwards compatiblity and procedures 
for interoperation.
>
>> Backwards compatibility
>> This was the main argument risen to ground MPLS-TP OAM on BFD. It's no

R: RE: [mpls] R: Re: LastCall: (Proactive Connectivity Verification,Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Standard

[erminio.ottone...@libero.it]

The technical concern raised during the WG poll has not been resolved so the 
history definetely matters.

Quoting RFC5921:

   There are thus two objectives for MPLS-TP:

   1.  To enable MPLS to be deployed in a transport network and operated
   in a similar manner to existing transport technologies.

   2.  To enable MPLS to support packet transport services with a
   similar degree of predictability to that found in existing
   transport networks.

Based on the extensive comments provided by transport operators and ITU-T 
community, the solution in this draft is useless in case 1.

The fact that the solution in this draft is not backward compatible with 
existing IP/MPLS BFD implementations means that this solution is also uselesee 
in case 2.

Are there other undocumented use cases for MPLS-TP deployments?

>Messaggio originale
>Da: nurit.sprec...@nsn.com
>Data: 7-lug-2011 11.59
>A: , , , 
"IETF-Announce"
>Cc: 
>Ogg: RE: [mpls] R: Re: LastCall:   
> 
(Proactive  ConnectivityVerification,Continuity Check and Remote Defect 
indicationfor   MPLSTransport   Profile) to Proposed Standard
>
>Erminio,
>I do not think the history is relevant for this specific discussion... 
>Also I find it inappropriate to give statements with no justifications
>behind. 
>You say: "the solution in this draft is useless for many MPLS-TP
>deployments.".  in order to seriously consider your comment, you have to
>show why it is useless and which requirements are not satisfied.
>Otherwise you cannot expect anyone to refer to your point. 
>Best regards,
>Nurit
>
>P.s. did you mean that the document is useless to available non-standard
>deployments, e.g. T-MPLS?
> 
>


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

R: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Stand

[erminio.ottone...@libero.it]

Do you mean that ITU-T comments were discussed and resolution agreed during the 
ITU-T meeting?

If this is the case, why the LS just provides the comments and not the agreed 
resolution?

Why some ITU-T comments have been then rejected?

>Messaggio originale
>Da: david.i.al...@ericsson.com
>Data: 6-lug-2011 19.35
>A: "erminio.ottone...@libero.it", "l...@pi.nu"
, "Rui Costa"
>Cc: "m...@ietf.org", "ietf@ietf.org", "IETF-
Announce"
>Ogg: RE: [mpls] R: Re: Last Call:  
> 
(Proactive Connectivity Verification, Continuity Check and Remote Defect 
indication for  MPLSTransport   Profile) to Proposed Standard
>
>Hi Erminio:
>
>Two of the three document editors were present at SG15 plenary in February 
where the comments originated. The revised meeting schedule resulted in a day 
spent going through the document with the editors. IMO there were lots of 
discussion and legitimate issues with the document identified and corrected so 
it was a useful session. The liaison of same was in many ways *after the 
fact*.
>
>Cheers
>Dave 
>


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

R: RE: [mpls] R: Re: Last Call: (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standa

[erminio.ottone...@libero.it]

>However this is a consequence of adapting an existing technology to a new 
application. I do not see any way around that. And the entire joint project was 
based on the premise of engineering re-use not greenfield design. That is what 
it said on the tin up front, and IMO why when the IETF started down this path 
packet transport transitioned from being a minority sport to mainstream, so it 
is a bit late to cry foul

This is not what the IETF has committed to deliver to ITU-T and in fact slide 
44 postpones to the OAM design phase "decide whether LSP-Ping or BFD can or 
should be tweaked or not" and slide 46 reckons "many options including non IP 
BFD is an option encapsulation of Y.1731 PDU"

It seems to me after having read the draft and followed this very long thread 
that tweaking BFD is not the right approach to meet ITU-T requirements so it 
would be worth evaluating the other alternative considered viable by the JWT 
which is encapulating Y.1731 PDUs.

>Messaggio originale
>Da: david.i.al...@ericsson.com
>Data: 6-lug-2011 20.24
>A: "erminio.ottone...@libero.it", 
"rco...@ptinovacao.pt", "ietf@ietf.org", 
"IETF-Announce"
>Cc: "m...@ietf.org"
>Ogg: RE: [mpls] R: Re: LastCall:   
> 
(Proactive  ConnectivityVerification,   Continuity Check and Remote 
Defect 
indication  for MPLSTransport   Profile) to Proposed Standard
>
>Hi Erminio:
>
>
>>Several service providers regarded this draft as not meeting their 
>>transport networks' needs.
>
>E> This is a true statement: the solution in this draft is useless for many 
MPLS- TP deployments.
>
>The two statements do not necessarily follow. 
>
>What we established during discussions at the SG15 plenary in February was 
that the issue some service providers had was that the IETF BFD solution 
exceeded their requirements in that there was additional functionality they did 
not see a need for, and that they considered any additional functionality 
parasitic.
>
>However this is a consequence of adapting an existing technology to a new 
application. I do not see any way around that. And the entire joint project was 
based on the premise of engineering re-use not greenfield design. That is what 
it said on the tin up front, and IMO why when the IETF started down this path 
packet transport transitioned from being a minority sport to mainstream, so it 
is a bit late to cry foul
>
>My 2 cents
>Dave
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard: request for max frame size

[Len Holgate]

Francis,

> Ok, It shouldn't be a negotiation but an indication to accommodate
> communication to each party.

Fair point.

> Ok, it is important to note the peer is limiting max frame 
> size not the
> message size which may be still infinite in practical terms (63
> bits)and we have fragmentation support to deal with this.

I understand. I was just pointing out that in your example, if the client
instead decided to limit the size of messages that it sent then then nothing
could cause any frames to be larger than that limit when they arrived at the
server.

> 1) Protocol problems should be solved on its layer, otherwise it will
>cause next layer (application level in this case) to need to solve
>them. It looks reasonable not forcing people to do so.

Agree.

> 2) In general, it has lot of benefits to fragment bigger messages into
>smaller pieces to avoid sick interactions. 

Agree.

> 3) No matter API style provided by a websocket stack (frame indication
> or stream oriented), having framing running in the background 
> where the
> sending peer and intermediaries can coalesce frames without any
> indication of the upper level will cause problems that can't be solved
> in practical terms by a receiving side. 

Agree.

Len
www.lenholgate.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Will McAfee]

While these notices have very little to no legal weight whatsoever, I firmly
believe that allowing their presence on our mailing list invites frivolous
lawsuits whose purpose is to cost the IETF money in the case that an
individual does not like what we are doing.  One does not need to look
particularly hard to find examples of ridiculous cases the plaintiff would
never win where the defendant chose to simply buy the privilege of making it
go away without taking on the costs and effort of actually fighting it in
court, no matter how certain the victory.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Michael Richardson]

> "Dave" == Dave CROCKER  writes:
>> 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 subject to any
>> privilege, can be disregarded for all purposes, and will be of no
>> force or effect."

Dave> It's excellent that the issue was covered in the RFC.

Dave> My question is how the contents of that RFC can be binding on
Dave> random IETF participants?

It can't, except that they agree to the terms when they sign up at the
web server.   If the IETF deleted posts that were marked confidential
then the IETF would be simply enforcing this.

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Dave CROCKER]

On 7/12/2011 2:36 PM, Jorge Contreras wrote:

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 subject to any privilege, can be disregarded for all purposes,
and will be of no force or effect."



Jorge,

It's excellent that the issue was covered in the RFC.

My question is how the contents of that RFC can be binding on random IETF 
participants?


I doubt many folk even know about the item, even if they know about the RFC and 
I don't see how they have agreed to those terms.


Has the force of this been tested?  That is, when there is a conflict between 
the conditions imposed by one of these email attachments and the terms in RFC 
5378, is there equivalent legal precedent for the RFC to win?


Thanks.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Michael Richardson]

> "Marc" == Marc Petit-Huguenin  writes:
Marc> No, I was serious.  I think that the best response to this
Marc> kind of stuff is to do what they ask to the letter.  If we can
Marc> convince the senders that annotating their notice with an
Marc> header will permit us to obey their request, everybody wins.

+1

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf