Re: Last Call: (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard

[Hannes Tschofenig]

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 restricted only to PSAP-to-first 
Responder, and PSAP-to-PSAP communication. 

It might also be useful to add that this document did not make it through the 
ECRIT working group. The document type is Standards Track and might give the 
impression that there is wide consensus behind the document -- but there isn't. 
IETF last calls may add a lot of value but I do not see that anyone had pointed 
to the various discussions in the ECRIT mailing list on that topic. 

I was always of the impression that the mechanism does not lead to any useful 
outcome. See previous discussions: 
Hannes: http://www.ietf.org/mail-archive/web/ecrit/current/msg05940.html
Henning: http://www.ietf.org/mail-archive/web/ecrit/current/msg05941.html
JamesW: http://www.ietf.org/mail-archive/web/ecrit/current/msg05945.html

For those who have not followed the work I would like to point out that we have 
an "marking" (or call it indication) of an emergency call already, it is called 
a Service URN - RFC 5031. How many times do we need to again identify that a 
call (or a message) is an emergency call? 

The document interestingly talks about closed networks or controlled 
environments where this is supposed to be used. I don't believe it is useful to 
do so because this leaves the door open to use the mechanism anywhere. Often, 
these networks are not as closed as we think. 

  This new namespace can be included in SIP requests to provide an
   explicit priority indication within controlled environments, such as
   an IMS infrastructure or Emergency Services network (ESInet) where
   misuse can be reduced to a minimum because these types of networks
   have great controls in place.

Btw, what are these >>great<< controls? 

My comments are addressed if the document (in the introduction) makes it clear 
that UAs' MUST NOT include this  RP namespace in an outgoing emergency call 
because there is already the Service URN marking that classifies the call as an 
emergency call. 
We had already agreed on this a long time ago, see 
http://www.ietf.org/mail-archive/web/ecrit/current/msg05960.html. Still, the 
text in the introduction and in the security consideration is very fuzzy and in 
my view intentionally does not make the case clear to leave it up to 
interpretation. 

It is ironic that this document manages to get finished before the major work 
of the ECRIT group, namely PhoneBCP, and ECRIT framework, get completed. (Or 
the SIPCORE SIP location conveyance for that matter as well.) 
Why would someone want to go with their work through a working group when they 
can get a Standards Track document faster and easier? 

Ciao
Hannes

On Jun 16, 2011, at 12:26 AM, The IESG wrote:

> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'IANA Registering a SIP Resource Priority Header Field Namespace for
>   Local Emergency Communications'
>   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-13. 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
> 
> 
>   This document creates the new Session Initiation Protocol (SIP)
>   Resource Priority header field namespace "esnet" for local emergency
>   usage to a public safety answering point (PSAP), between PSAPs, and
>   between a PSAP and first responders and their organizations, and
>   places this namespace in the IANA registry.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

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

[Mark Nottingham]

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.
>> 
>> Defining a bucket for potentially random, unassociated metadata in a
>> single URI is, IMO, asking for trouble; if it is successful, it could
>> cause administrative issues on the server (as potentially many
>> parties will need control of a single file, for different uses --
>> tricky 

Re: Confidentiality notices on email messages

[Michael Richardson]

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 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: Last Call: (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC

[Barry Leiba]

> 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 as IESG statements, Web Pages, or
were discarded.

NEW
All IONs were republished as IESG statements, republished as Web Pages,
or discarded.


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.

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

Re: Last Call: (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC

[Peter Saint-Andre]

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
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Andrew Sullivan]

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 purposes, and will be of no force or effect."
> 
> Yes, I'm aware of that.  My point was exactly that: that the
> confidentiality statement is pointless.

Actually, given the policy, it's _not_ pointless.  It makes the
message "of no force or effect" and causes the participation by that
individual to be disregarded.  Surely nobody wants their contribution
to be disregarded because of a misguided rule on the part of someone
in their firm who doesn't understand the meaning of the words "public
mailing list".

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: Last Call: (Conclusion of FYI RFC Sub-series) to Informational RFC

[Russ Housley]

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 
> http://www.rfc-editor.org/pipermail/rfc-interest/2011-June/002519.html as 
> Last Call comments.  Mykyta.
> 
> 10.06.2011 16:18, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Conclusion of FYI RFC Sub-series'
>> as an Informational RFC
>> 
>> [ . . . ]

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

Re: Confidentiality notices on email messages

[Marc Petit-Huguenin]

-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
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.

> 
> I also think that we should enforce 77 columns max for text/plain when
> there is no "format=flowed" option in the Content-Type.
> 


- -- 
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)

iEYEARECAAYFAk4dyhAACgkQ9RoMZyVa61eBugCfZCSPrGvFRzKQnJsfplGxZexp
MCwAoIrKHYpNxpTA85BJL1Oll3JHOF+P
=k4yT
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Alessandro Vesely]

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 
> 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.

+1, I am quite concerned by those unneeded clots of legal wisdom
infesting more and more places.  Couldn't they be concise, at least?
A confidentiality notice shouldn't need to thoroughly explain the
legal meaning of the term "confidential"...  Rather than formulate the
law so as to leverage the Internet, legal systems at times seem to be
hindering it with questionable obligations.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC

[Mykyta Yevstifeyev]

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:

OLD
All IONs were republished whether as IESG statements, Web Pages, or
were discarded.

NEW
All IONs were republished as IESG statements, republished as Web Pages,
or discarded.

I 'll make this correction.



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.
Based on the feedback received, I won't include this subsection in the 
draft.


Mykyta


Barry



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

Re: Confidentiality notices on email messages

[Marc Petit-Huguenin]

-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 confidentiality notices.
>>
>> 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.
> 
> +1, I am quite concerned by those unneeded clots of legal wisdom
> infesting more and more places.  Couldn't they be concise, at least?
> A confidentiality notice shouldn't need to thoroughly explain the
> legal meaning of the term "confidential"...  Rather than formulate the
> law so as to leverage the Internet, legal systems at times seem to be
> hindering it with questionable obligations.

I do not think that size is really the issue.  It can even make things worse - I
saw some attempts (from Cisco people I think) to use a link instead of a
complete notice, but now I have to click on the link and read the web page,
which takes more time than reading an embedded text.

Using a specific MIME type for the notice text itself permits to not display it
if my mailer is configured this way.  If in addition we have an Header field
that describes the restrictions detailed in the disclaimer text, then we can 1)
configure IETF mailing-lists to bounce emails that clash with IETF's Note Well
and 2) configure our individual mailer to bounce emails with a confidentiality
notice but that are not sent specifically to us.

- -- 
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)

iEUEARECAAYFAk4d0f4ACgkQ9RoMZyVa61eGkQCfXPhQ/yTDEDNiQRbff/eYE+y/
QScAmNGXVlGBQBm9QVx3IegUTo9QJrU=
=X41v
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Repetitions and consensus

[Greg Wilkins]

On 13 July 2011 08:51, Martin Rex  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 is a widely held opinion, even if it comes from few repeated
voices and even if they are intellectually aware of the actual count.
So even if there is no actual conscious opinion counting going on, our
brains are doing it for us and it does influence us.

I 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 influenced by repetition
and even if chairs/ADs are aware of this fact.   It shows that
subjective measures are subject to manipulation.

I 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 influenced by repetition
and even if chairs/ADs are aware of this fact.   It shows that
subjective measures are subject to manipulation.

I 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 influenced by repetition
and even if chairs/ADs are aware of this fact.   It shows that
subjective measures are subject to manipulation.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART review of draft-polk-local-emergency-rph-namespace-01

[david.black]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at .

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-polk-local-emergency-rph-namespace-01
Reviewer: David L. Black
Review Date: July 12, 2011
IETF LC End Date: July 13, 2011

Summary:
This draft is basically ready for publication, but has nits that should be 
fixed before publication.

This draft defines a SIP Resource Priority header namespace, "esnet", for use in
providing preferential treatment to emergency calls (e.g., from on-scene 
responders).

This field is an addition to rather than a replacement for existing notions of
priority in the SIP Resource Priority header.  Section 2 explains why this was
done, but section 2 is a bit sloppy and imprecise.  Some level of imprecision is
necessary as this draft deliberately does not specify how this header namespace
is used to provide preferential treatment.  Nonetheless, the following two items
could be improved in Section 2's discussion:

1) Explain the reason for including the second paragraph, the paragraph
that references RFC 4412's discouragement of modification of priorities
within an administrative domain.  That paragraph's not connected to the
rest of section 2.
2) Explicitly state that one of the anticipated uses of the priorities in the
esnet namespace is to override the ordinary priorities found elsewhere 
in
the Resource Priority header.

Small nit: There's an extraneous "to" in the first line of section 3:

   The "esnet" namespace should not to be considered generic for all
^^

idnits 2.12.12 found a few formatting problems:

  == You're using the IETF Trust Provisions' Section 6.b License Notice from
 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
 http://trustee.ietf.org/license-info/)

  == It seems as if not all pages are separated by form feeds - found 0 form
 feeds but 7 pages

  == The copyright year in the IETF Trust and authors Copyright Line does not
 match the current year


Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754


___
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

[Greg Wilkins]

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 - potentially
binary chopping down to find an acceptable size, which might be sub
optimal.

I simple optional header in the handshake declaring the max frame size
(which intermediaries could adjust) would be very complimentary to the
existing fragmentation and 1004 features and I can't think of any
significant down side.

regards

On 13 July 2011 00:13, Francis Brosnan Blazquez  wrote:
> Hi,
>
> Recently, I posted [1] that websocket protocol should include an
> indication about max frame size that is willing to accept the connecting
> peer.
>
> Many pointed this is not an issue because you could use a stream
> oriented API (like TCP send/recv and others), but that only bypasses the
> problem (in some cases) not solves it.
>
> Websocket protocol is frame based and every frame based protocol
> designed until now has/need such feature or similar. Even TCP, for those
> that proposes to use a stream oriented API as a solution, includes a
> more complex mechanism than a simple max frame size (window based ack),
> so each party can control/inform the sender. This is critical.
>
> A good example for this would be the next. Let suppose you have a
> constrained memory device (either because it is small or because it
> accepts a large amount of connections). On that device you deploy a
> websocket app that only accepts small messages (< 512 bytes, let's
> say).
>
> In this context, you can hard code at your web app (javascript) that
> must not send messages larger than this size (so you control websocket
> payload size) and in the case you need to, you must split them
> properly.
>
> However, even with this mechanism, you have no warranty that the browser
> or an intermediary will join those messages into a single frame, causing
> your device to receive a bigger message/frame than expected.
>
> Assuming this I think we would require either to include a
> Max-Frame-Size indication (or a really poor solution: to explicitly
> state on the draft that frames must not be coalesced by intermediaries
> or browsers).
>
> Regards,
>
> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html
> --
> Francis Brosnan Blázquez 
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
>
> AVISO LEGAL
>
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
>
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le informamos de
> que sus datos de carácter personal, recogidos de fuentes accesibles al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
>
> ___
> hybi mailing list
> h...@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
___
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,

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 doesn't matter
what intermediaries do to the frames as the maximum frame size would be
limited to the maximum message size that the client sends. The only time
this wouldn't work is if you were using a 'message of infinite fragments'
where you start with a fragmented frame and don't know when you'll send the
final fragment.

The communication between peers about maximum message sizes supported could
just as easily be in the application level protocol that you're running over
the websocket connection.

Len
www.lenholgate.com

> -Original Message-
> From: hybi-boun...@ietf.org [mailto:hybi-boun...@ietf.org] On 
> Behalf Of Francis Brosnan Blazquez
> Sent: 12 July 2011 15:14
> To: Hybi
> Cc: ietf@ietf.org; draft-ietf-hybi-thewebsocketproto...@tools.ietf.org
> Subject: Re: [hybi] Last Call: 
>  (The WebSocket 
> protocol) to Proposed Standard: request for max frame size
> 
> Hi,
> 
> Recently, I posted [1] that websocket protocol should include an
> indication about max frame size that is willing to accept the 
> connecting
> peer. 
> 
> Many pointed this is not an issue because you could use a stream
> oriented API (like TCP send/recv and others), but that only 
> bypasses the
> problem (in some cases) not solves it.
> 
> Websocket protocol is frame based and every frame based protocol
> designed until now has/need such feature or similar. Even 
> TCP, for those
> that proposes to use a stream oriented API as a solution, includes a
> more complex mechanism than a simple max frame size (window 
> based ack),
> so each party can control/inform the sender. This is critical.
> 
> A good example for this would be the next. Let suppose you have a
> constrained memory device (either because it is small or because it
> accepts a large amount of connections). On that device you deploy a
> websocket app that only accepts small messages (< 512 bytes, let's
> say). 
> 
> In this context, you can hard code at your web app (javascript) that
> must not send messages larger than this size (so you control websocket
> payload size) and in the case you need to, you must split them
> properly. 
> 
> However, even with this mechanism, you have no warranty that 
> the browser
> or an intermediary will join those messages into a single 
> frame, causing
> your device to receive a bigger message/frame than expected.
> 
> Assuming this I think we would require either to include a
> Max-Frame-Size indication (or a really poor solution: to explicitly
> state on the draft that frames must not be coalesced by intermediaries
> or browsers). 
> 
> Regards,
> 
> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html
> -- 
> Francis Brosnan Blázquez 
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
> 
> AVISO LEGAL
> 
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y 
> sometidos a secreto
> profesional, se prohíbe divulgarlos, en virtud de las leyes 
> vigentes. Si
> usted no lo es y lo ha recibido por error o tiene 
> conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
> 
> En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> diciembre, de Protección de Datos de Carácter Personal, le 
> informamos de
> que sus datos de carácter personal, recogidos de fuentes accesibles al
> público o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y oposición dispuestos en la mencionada Ley
> Orgánica, notificándolo por escrito a:
> ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> Henares (Madrid).
> 
> ___
> hybi mailing list
> h...@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 

___
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]

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 Message-
> From: hybi-boun...@ietf.org [mailto:hybi-boun...@ietf.org] On 
> Behalf Of Greg Wilkins
> Sent: 13 July 2011 03:54
> To: Francis Brosnan Blazquez
> Cc: Hybi; ietf@ietf.org; 
> draft-ietf-hybi-thewebsocketproto...@tools.ietf.org
> Subject: Re: [hybi] Last Call: 
>  (The WebSocket 
> protocol) to Proposed Standard: request for max frame size
> 
> 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 - potentially
> binary chopping down to find an acceptable size, which might be sub
> optimal.
> 
> I simple optional header in the handshake declaring the max frame size
> (which intermediaries could adjust) would be very complimentary to the
> existing fragmentation and 1004 features and I can't think of any
> significant down side.
> 
> regards
> 
> On 13 July 2011 00:13, Francis Brosnan Blazquez 
>  wrote:
> > Hi,
> >
> > Recently, I posted [1] that websocket protocol should include an
> > indication about max frame size that is willing to accept 
> the connecting
> > peer.
> >
> > Many pointed this is not an issue because you could use a stream
> > oriented API (like TCP send/recv and others), but that only 
> bypasses the
> > problem (in some cases) not solves it.
> >
> > Websocket protocol is frame based and every frame based protocol
> > designed until now has/need such feature or similar. Even 
> TCP, for those
> > that proposes to use a stream oriented API as a solution, includes a
> > more complex mechanism than a simple max frame size (window 
> based ack),
> > so each party can control/inform the sender. This is critical.
> >
> > A good example for this would be the next. Let suppose you have a
> > constrained memory device (either because it is small or because it
> > accepts a large amount of connections). On that device you deploy a
> > websocket app that only accepts small messages (< 512 bytes, let's
> > say).
> >
> > In this context, you can hard code at your web app (javascript) that
> > must not send messages larger than this size (so you 
> control websocket
> > payload size) and in the case you need to, you must split them
> > properly.
> >
> > However, even with this mechanism, you have no warranty 
> that the browser
> > or an intermediary will join those messages into a single 
> frame, causing
> > your device to receive a bigger message/frame than expected.
> >
> > Assuming this I think we would require either to include a
> > Max-Frame-Size indication (or a really poor solution: to explicitly
> > state on the draft that frames must not be coalesced by 
> intermediaries
> > or browsers).
> >
> > Regards,
> >
> > [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html
> > --
> > Francis Brosnan Blázquez 
> > ASPL
> > 91 134 14 22 - 91 134 14 45 - 91 116 07 57
> >
> > AVISO LEGAL
> >
> > Este mensaje se dirige exclusivamente a su destinatario. Los datos
> > incluidos en el presente correo son confidenciales y 
> sometidos a secreto
> > profesional, se prohíbe divulgarlos, en virtud de las leyes 
> vigentes. Si
> > usted no lo es y lo ha recibido por error o tiene 
> conocimiento del mismo
> > por cualquier motivo, le rogamos que nos lo comunique por 
> este medio y
> > proceda a destruirlo o borrarlo.
> >
> > En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
> > diciembre, de Protección de Datos de Carácter Personal, le 
> informamos de
> > que sus datos de carácter personal, recogidos de fuentes 
> accesibles al
> > público o datos que usted nos ha facilitado previamente, proceden de
> > bases de datos propiedad de Advanced Software Production Line, S.L.
> > (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> > rectificación, cancelación y oposición dispuestos en la 
> mencionada Ley
> > Orgánica, notificándolo por escrito a:
> > ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
> > Henares (Madrid).
> >
> > ___
> > hybi mailing list
> > h...@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> ___
> hybi mailing list
> h...@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 

___
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

[Francis Brosnan Blazquez]

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 adjust this unless
> they're only allowed to reduce the amount...

My impression is that this max frame size value would help
intermediaries, and peers, to know how to fragment or coalesce
application level messages. Without such indication they are blind...

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

RE: [Ecrit] Last Call: (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard

[DRAGE, Keith (Keith)]

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 is no reason why it cannot be used by 
the first network operator provided entity that identifies an emergency call. I 
agree it is not applicable to the IETF solution, but then you have no network 
operator to provide you with priority in the first place.

If a network operator want to provide priority in their equipment after point 
of entry to the network, to an emergency call, then RPH is the sensible way of 
doing it, and not forcing them to recognize multiple different parameters to 
identify that priority is needed.

You seem to be back in cloud cuckoo land where you believe all emergency calls 
are handled by the IETF ECRIT solution.

Keith

> -Original Message-
> From: ecrit-boun...@ietf.org [mailto:ecrit-boun...@ietf.org] On Behalf Of
> Hannes Tschofenig
> Sent: 13 July 2011 10:21
> To: ietf@ietf.org IETF; ec...@ietf.org
> Subject: Re: [Ecrit] Last Call:  01.txt> (IANA Registering a SIP Resource Priority Header Field Namespace
> for Local Emergency Communications) to Proposed Standard
> 
> 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 restricted only to PSAP-to-first
> Responder, and PSAP-to-PSAP communication.
> 
> It might also be useful to add that this document did not make it through
> the ECRIT working group. The document type is Standards Track and might
> give the impression that there is wide consensus behind the document --
> but there isn't. IETF last calls may add a lot of value but I do not see
> that anyone had pointed to the various discussions in the ECRIT mailing
> list on that topic.
> 
> I was always of the impression that the mechanism does not lead to any
> useful outcome. See previous discussions:
> Hannes: http://www.ietf.org/mail-archive/web/ecrit/current/msg05940.html
> Henning: http://www.ietf.org/mail-archive/web/ecrit/current/msg05941.html
> JamesW: http://www.ietf.org/mail-archive/web/ecrit/current/msg05945.html
> 
> For those who have not followed the work I would like to point out that we
> have an "marking" (or call it indication) of an emergency call already, it
> is called a Service URN - RFC 5031. How many times do we need to again
> identify that a call (or a message) is an emergency call?
> 
> The document interestingly talks about closed networks or controlled
> environments where this is supposed to be used. I don't believe it is
> useful to do so because this leaves the door open to use the mechanism
> anywhere. Often, these networks are not as closed as we think.
> 
>   This new namespace can be included in SIP requests to provide an
>explicit priority indication within controlled environments, such as
>an IMS infrastructure or Emergency Services network (ESInet) where
>misuse can be reduced to a minimum because these types of networks
>have great controls in place.
> 
> Btw, what are these >>great<< controls?
> 
> My comments are addressed if the document (in the introduction) makes it
> clear that UAs' MUST NOT include this  RP namespace in an outgoing
> emergency call because there is already the Service URN marking that
> classifies the call as an emergency call.
> We had already agreed on this a long time ago, see
> http://www.ietf.org/mail-archive/web/ecrit/current/msg05960.html. Still,
> the text in the introduction and in the security consideration is very
> fuzzy and in my view intentionally does not make the case clear to leave
> it up to interpretation.
> 
> It is ironic that this document manages to get finished before the major
> work of the ECRIT group, namely PhoneBCP, and ECRIT framework, get
> completed. (Or the SIPCORE SIP location conveyance for that matter as
> well.)
> Why would someone want to go with their work through a working group when
> they can get a Standards Track document faster and easier?
> 
> Ciao
> Hannes
> 
> On Jun 16, 2011, at 12:26 AM, The IESG wrote:
> 
> >
> > The IESG has received a request from an individual submitter to consider
> > the following document:
> > - 'IANA Registering a SIP Resource Priority Header Field Namespace for
> >   Local Emergency Communications'
> >   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-13. Exceptionally, comments may
> be
> > sent to i...@ietf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated so

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

[Len Holgate]

> > 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 unless
> > they're only allowed to reduce the amount...
> 
> My impression is that this max frame size value would help
> intermediaries, and peers, to know how to fragment or coalesce
> application level messages. Without such indication they are blind...

I agree.

Len
www.lenholgate.com

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

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

[D'Alessandro Alessandro Gerardo]

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 in G-ACh e CC/CV mode in G-ACh.
Do all of them satisfy transport requirements?
I understand they are not interoperable (as well as the two BFD mode 
for the same CC/CV in G-Ach encapsulation). Is it correct?

Best regards,
Alessandro

--
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07


-Messaggio originale-
Da: mpls-boun...@ietf.

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

[Francis Brosnan Blazquez]

> 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 merge complete messages. If, in your example, your
> client limited itself to messages of a certain size

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.

This way intermediaries can split/coalesce fragments according to
receiving peer expectation.

>  then it doesn't matter
> what intermediaries do to the frames as the maximum frame size would be
> limited to the maximum message size that the client sends. The only time
> this wouldn't work is if you were using a 'message of infinite fragments'
> where you start with a fragmented frame and don't know when you'll send the
> final fragment.

Assuming frame size and message size aren't equal, it does matter. 

> The communication between peers about maximum message sizes supported could
> just as easily be in the application level protocol that you're running over
> the websocket connection.

Ok, I see you point and in part you are right, but there is a risk with
this argument:

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.

 Side note: our intention is to layer BEEP on top of websocket, so,
 in practical terms this is not a problem for us because it will
 provide us with all the protection and flow control required.

 However it looks to me this is not a solution for people using
 websocket in other contexts.

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

   For example, if you send a really large frame, you won't be able to
   send a control message in the middle until you finish sending the
   frame in place. 

   Having a max frame size indication will help websocket stacks to
   fragment using the right value for each application.

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. 

In other words, I think having a framing without a max frame size
mechanism (or other mech like ack confirmation, its the same) is like
pretending having a coin with only one side.

> Len
> www.lenholgate.com
> 
> > -Original Message-
> > From: hybi-boun...@ietf.org [mailto:hybi-boun...@ietf.org] On 
> > Behalf Of Francis Brosnan Blazquez
> > Sent: 12 July 2011 15:14
> > To: Hybi
> > Cc: ietf@ietf.org; draft-ietf-hybi-thewebsocketproto...@tools.ietf.org
> > Subject: Re: [hybi] Last Call: 
> >  (The WebSocket 
> > protocol) to Proposed Standard: request for max frame size
> > 
> > Hi,
> > 
> > Recently, I posted [1] that websocket protocol should include an
> > indication about max frame size that is willing to accept the 
> > connecting
> > peer. 
> > 
> > Many pointed this is not an issue because you could use a stream
> > oriented API (like TCP send/recv and others), but that only 
> > bypasses the
> > problem (in some cases) not solves it.
> > 
> > Websocket protocol is frame based and every frame based protocol
> > designed until now has/need such feature or similar. Even 
> > TCP, for those
> > that proposes to use a stream oriented API as a solution, includes a
> > more complex mechanism than a simple max frame size (window 
> > based ack),
> > so each party can control/inform the sender. This is critical.
> > 
> > A good example for this would be the next. Let suppose you have a
> > constrained memory device (either because it is small or because it
> > accepts a large amount of connections). On that device you deploy a
> > websocket app that only accepts small messages (< 512 bytes, let's
> > say). 
> > 
> > In this context, you can hard code at your web app (javascript) that
> > must not send messages larger than this size (so you control websocket
> > payload size) and in the case you need to, you must split them
> > properly. 
> > 
> > However, even with this mechanism, you have no warranty that 
> > the browser
> > or an intermediary will join those messages into a single 
> > frame, causing
> > your device to receive a bigger message/frame than expected.
> > 
> > Assuming this I think we would require either to include a
> > Max-Frame-Size indication (or a really poor solution: to explicitly
> > state on the draft that frames must not be coalesced by intermediaries
> > or browsers). 
> > 
> > Regards,
> > 

Re: Confidentiality notices on DNS messages

[Bert]

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 up in the DNS 

e.g the BSRPDNSC implementation[*] returns a disclaimer:


dig 10.sin.5.+.rp.secret-wg.org TXT
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.6.0-APPLE-P2 <<>> 10.sin.5.+.rp.secret-wg.org TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14586
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;10.sin.5.+.rp.secret-wg.org. INTXT

;; ANSWER SECTION:
10.sin.5.+.rp.secret-wg.org. 10 IN TXT "4.45597888911063"
10.sin.5.+.rp.secret-wg.org. 10 IN TXT "This DNS message (including the RR(s) 
in the additional section) is confidential, proprietary, may be subject to 
copyright and legal privilege and no related rights are waived." "If you are 
not the intended recipient or its agent, any review, dissemination, 
distribution or copying of this DNS message or any of its content is strictly 
prohibited and may be unlawful." "All messages may be monitored as permitted by 
applicable law and regulations and our policies to protect our business." "DNS 
messages are not secure and you are deemed to have accepted any risk if you 
communicate with us using DNS." "If received in error, please notify us 
immediately and delete the DNS message (and any of its sections) from any 
computer or any storage medium without printing a copy."

;; Query time: 34 msec
;; SERVER: 213.154.224.155#53(213.154.224.155)
;; WHEN: Wed Jul 13 10:17:21 2011
;; MSG SIZE  rcvd: 851





-- Bert's secretary


[*] BSRPDNSC:  Bert's Secure Reverse Polish DNS Calculator 
http://bert.secret-wg.org/Tools/index.html#Tool_3
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Looking for room at Hilton

[Paul Sangster]

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

Re: Repetitions and consensus

[todd glassey]

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 fact. I 
mean as much as years later there needs to be proof that all IETF 
practices were fair and open - something that they are so far from its 
almost funny.

--

Todd S. Glassey
This is from my personal email account and any materials from this account come 
with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

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

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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 helpful rather than harmful.


Yours,
Joel

On 7/12/2011 8:26 PM, Joe Touch wrote:



On 7/12/2011 3:36 PM, Stewart Bryant wrote:

On 12/07/2011 23:23, Joe Touch wrote:

Hi, Joel (et al.),

On 7/10/2011 7:10 AM, Joel Halpern wrote:

Joe,
THE KARP WG Chairs have reviewed your comments, in order to figure out
what the best way to address them. We would appreciate it if you could
engage in discussion of this proposal on the KARP working group email
list. If you feel we are still not understanding your point, we
would be
happy to make some time avaialble for discussion at the WG session in
Quebec City. (Comments from anyone else, particularly WG members, on
the
proposals being made by the WG chairs are appreciated as well.)

Rather than a line by line response, we have tried to find the common
themes and respond to them. If we have missed major issues, please let
us know.

You raised concern about the use of the term "on-the-wire." Rather than
replace the term, we would prefer to add descriptive text early in the
document. 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 document it is used to refer to the message sent from one routing
process to another.


That's a great example of why this term should be removed. The message
sent from one BGP to another is sent *inside* a TCP connection, and
nobody would ever call the TCP bytestream payload the message "on the
wire".

This term is simply sloppy, and just as the security community rightly
raises issues with similarly poor use of its terms (e.g., "random"
where pseudorandom or arbitrary are intended, or "authenticated" where
integrity protection is intended), I consider this a *significant*
transport issue.


Joe

Please can you suggest a suitable generic term that covers the
set of cases that we need to deal with in routing - i.e.
over the MAC, over IP, over UDP and over TCP, so that we can
discuss inter routing entity message passing as an abstract
operation.

As Joel says when we get to the detailed design of each routing
protocol we will discuss the details, but we want a high level
discussion in this document.

Note BTW that 186 RFCs use the term "on the wire" in this
sort of situation.


I counted nearly 210, when including "over the wire" too. There are
similar misuses of, e.g., security terms, though, so let's not let past
errors suggest continued use.

That said, let's proceed:

First, when you say "on the wire" do you mean:

(A)- the routing protocol data units (RPDUs)

(B)- way in which RPDUs are exchanged
this includes message payloads, meta-info
(header information), and any other info
at other layers beyond RPDUs that the routing
protocol uses or relies upon

I'm presuming the term "on the wire" is intended to differentiate
between (A) and (B).

There's no good way to describe (B) as a single entity because it's not
one. You basically are differentiating between the message and the means
of its communication. The latter is often called a 'channel' in other
contexts, so maybe that's the term you want - a way to protect the
'channel'.

Joe







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

Re: Repetitions and consensus

[Fred Baker]

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 Repetitive Voice Can Sound Like a Chorus". 

We deal with that quite a bit. I can think of discussions in v6ops and on this 
list in which a single person contributed one message in four in a 200+ message 
thread, and although he was the lone speaker with that viewpoint, my co-chair 
told me he thought we lacked consensus.

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, concurrence, accord, unity, unanimity, solidarity; formal 
concord") coupled with listening carefully to those who disagree and 
determining whether their arguments actually make sense and point up an issue. 
I will recognize a single person's point at issue if it appears that they are 
not being listened to or their issue dealt with. If they are simply hammering a 
point, and their point is incorrect, I will note that they have been hammering 
an incorrect point ("even though you are sending one email in four in a long 
thread and are expressing extreme concern about a draft because it does , I 
will overlook your objections because it doesn't do that.") and move on.

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

Re: notes from discussion of KARP design guidelines

[Joe Touch]

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, but their views vary widely.



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 helpful rather than harmful.


Since the whole point of this doc centers around protecting the way 
messages are exchanged, not the messages themselves (e.g., as would be 
the case with signed BGP routes), this is a crucial issue to make clear 
and precise in this doc.


Joe


On 7/12/2011 8:26 PM, Joe Touch wrote:



On 7/12/2011 3:36 PM, Stewart Bryant wrote:

On 12/07/2011 23:23, Joe Touch wrote:

Hi, Joel (et al.),

On 7/10/2011 7:10 AM, Joel Halpern wrote:

Joe,
THE KARP WG Chairs have reviewed your comments, in order to figure out
what the best way to address them. We would appreciate it if you could
engage in discussion of this proposal on the KARP working group email
list. If you feel we are still not understanding your point, we
would be
happy to make some time avaialble for discussion at the WG session in
Quebec City. (Comments from anyone else, particularly WG members, on
the
proposals being made by the WG chairs are appreciated as well.)

Rather than a line by line response, we have tried to find the common
themes and respond to them. If we have missed major issues, please let
us know.

You raised concern about the use of the term "on-the-wire." Rather
than
replace the term, we would prefer to add descriptive text early in the
document. 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 document it is used to refer to the message sent from one routing
process to another.


That's a great example of why this term should be removed. The message
sent from one BGP to another is sent *inside* a TCP connection, and
nobody would ever call the TCP bytestream payload the message "on the
wire".

This term is simply sloppy, and just as the security community rightly
raises issues with similarly poor use of its terms (e.g., "random"
where pseudorandom or arbitrary are intended, or "authenticated" where
integrity protection is intended), I consider this a *significant*
transport issue.


Joe

Please can you suggest a suitable generic term that covers the
set of cases that we need to deal with in routing - i.e.
over the MAC, over IP, over UDP and over TCP, so that we can
discuss inter routing entity message passing as an abstract
operation.

As Joel says when we get to the detailed design of each routing
protocol we will discuss the details, but we want a high level
discussion in this document.

Note BTW that 186 RFCs use the term "on the wire" in this
sort of situation.


I counted nearly 210, when including "over the wire" too. There are
similar misuses of, e.g., security terms, though, so let's not let past
errors suggest continued use.

That said, let's proceed:

First, when you say "on the wire" do you mean:

(A)- the routing protocol data units (RPDUs)

(B)- way in which RPDUs are exchanged
this includes message payloads, meta-info
(header information), and any other info
at other layers beyond RPDUs that the routing
protocol uses or relies upon

I'm presuming the term "on the wire" is intended to differentiate
between (A) and (B).

There's no good way to describe (B) as a single entity because it's not
one. You basically are differentiating between the message and the means
of its communication. The latter is often called a 'channel' in other
contexts, so maybe that's the term you want - a way to protect the
'channel'.

Joe







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

Re: Repetitions and consensus

[Doug Barton]

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, concurrence, accord, unity, unanimity, solidarity; 
> formal concord") coupled with listening carefully to those who disagree and 
> determining whether their arguments actually make sense and point up an 
> issue. I will recognize a single person's point at issue if it appears that 
> they are not being listened to or their issue dealt with. If they are simply 
> hammering a point, and their point is incorrect, I will note that they have 
> been hammering an incorrect point ("even though you are sending one email in 
> four in a long thread and are expressing extreme concern about a draft 
> because it does , I will overlook your objections because it doesn't do 
> that.") and move on.

Fred has stated in a much more elegant and complete way what I was
trying to get across the other day when I said "consensus is not the
same as universal agreement."

And I'd also like to, um, repeat support for the concepts discussed in
the article Brian posted. I actually studied social psych. a bit in
college and even way back then these ideas were well understood. Deeply
ingrained human tendencies on both individual and group levels really
militate against what most people would consider to be rational,
objective thought on just about any topic. It gets worse geometrically
when it's something about which you care deeply.

An interesting site that approaches these topics from a fun, although
comparatively rigorous viewpoint is http://youarenotsosmart.com/. Of
particular interest to this group are the articles on confirmation bias,
and the Texas sharpshooter fallacy.


Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

Re: notes from discussion of KARP design guidelines

[Wesley Eddy]

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 clear.  A sentence to
clarify up-front what the definition is in this document might be
enough.



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 helpful rather than harmful.


It might be reasonable to add a sentence that says, "In this document,
'on the wire' refers to (A) the routing protocol data itself, as well
as (B) the way in which routing protocol data is exchanged using
underlying protocols, including the headers and other meta-data used by
those underlying protocols", or something like that?

To me, that's a lot more useful than saying "this term is commonly
used" without defining in what sense(s) you mean it in the present
document.

I think it's important because the protections possible are
potentially a lot different, and if you want people to think
about only one or both, it should be made explicit.

On a lighter note, I once generated a lot of confusion using this
term with people working on satellite networks, who were wondering
what wires I could possibly be talking about since all of our links
were microwave.  I guess if KARP covered MANET protocols we'd have
to protect them "on the wireless".

--
Wes Eddy
MTI Systems
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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 
document it is used to refer to the message sent from one routing 
process to another.


Apparently, this does not address Joe's concern.

Yours,
Joel

On 7/13/2011 2:24 PM, Wesley Eddy wrote:

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 clear. A sentence to
clarify up-front what the definition is in this document might be
enough.


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

Re: notes from discussion of KARP design guidelines

[Wesley Eddy]

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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.

Apparently, this does not address Joe's concern.



"message sent from one routing process to another" doesn't seem to be
right to me either since it sounds like the first definition that
covers routing protocol data only, and not underlying protocols, so I
wouldn't expect that proposal to address Joe's concern.

--
Wes Eddy
MTI Systems
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: notes from discussion of KARP design guidelines

[Joe Touch]

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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are 
exchanged?


From the intro:
   Four main steps were identified for that tightening:

  o  More secure mechanisms and practices for operating routers.
   ...

  o  Cleaning up the Internet Routing Registry repository [IRR],
   ...

  o  Specifications for cryptographic validation of routing message
 content.
   ...

  o  Securing the routing protocols' packets on the wire

   This document addresses the last bullet, securing the packets on the
   wire of the routing protocol exchanges.

So this document is clearly NOT about "the message from one routing 
process to another (that would be 'routing message content', IMO). I.e., 
this doc focuses on securing the transfer mechanism NOT the message.


Thus this is the key to the entirety of the doc. This doc needs to be 
very clear about what this is, at which point it can certainly also then 
refer back to the original RFC (e.g., "this is referred to in RFC 4948 
as 'on the wire'").


Joe


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

Re: Repetitions and consensus

[Hector Santos]

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 if there was a healthy sampling of 
participants, at some point, its filtered by osmosis and often there 
is already an handicap with editors providing +1s the WG has to 
overcome when a change is in disagreement but doesn't reach the "rough 
consensus."   In my view, the process is outdated. It may sense 20-30 
years ago when there were still a world of unknowns and hard "rough 
consensus" decisions had to made.  But today, to me, a rough consensus 
made - both sides are worthy ideas and compromises need to made rather 
than a cold cutoff of nearly half a WG.  My opinion.


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 Popularity of an Opinion From Its Familiarity: A Repetitive Voice Can Sound Like a Chorus". 


We deal with that quite a bit. I can think of discussions in v6ops and on this 
list in which a single person contributed one message in four in a 200+ message 
thread, and although he was the lone speaker with that viewpoint, my co-chair 
told me he thought we lacked consensus.

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, concurrence, accord, unity, unanimity, 
solidarity; formal concord") coupled with listening carefully to those who disagree and 
determining whether their arguments actually make sense and point up an issue. I will recognize a 
single person's point at issue if it appears that they are not being listened to or their issue 
dealt with. If they are simply hammering a point, and their point is incorrect, I will note that 
they have been hammering an incorrect point ("even though you are sending one email in four in 
a long thread and are expressing extreme concern about a draft because it does , I will 
overlook your objections because it doesn't do that.") and move on.

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




--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



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

Re: Repetitions and consensus

[Keith Moore]

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 Popularity of an Opinion From Its 
>> Familiarity: A Repetitive Voice Can Sound Like a Chorus". 
> 
> We deal with that quite a bit. I can think of discussions in v6ops and on 
> this list in which a single person contributed one message in four in a 200+ 
> message thread, and although he was the lone speaker with that viewpoint, my 
> co-chair told me he thought we lacked consensus.

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 vigorously and to respond to numerous attacks on not only his 
viewpoint but also his legitimacy, motivation, character, etc., there is a 
tendency among some to dismiss his opinions even more.

All of these clearly happened in recent discussions in v6ops.

It's certainly true that one lone speaker should not be able to deny rough 
consensus to a group.  That's why the consensus only has to be "rough".   But 
if the group doesn't even try to understand a minority view, it cannot be said 
to have tried to reach consensus of any kind.

> 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, concurrence, accord, unity, unanimity, solidarity; 
> formal concord") coupled with listening carefully to those who disagree and 
> determining whether their arguments actually make sense and point up an 
> issue. I will recognize a single person's point at issue if it appears that 
> they are not being listened to or their issue dealt with. If they are simply 
> hammering a point, and their point is incorrect, I will note that they have 
> been hammering an incorrect point ("even though you are sending one email in 
> four in a long thread and are expressing extreme concern about a draft 
> because it does , I will overlook your objections because it doesn't do 
> that.") and move on.

I'd agree with that logic.  Though I note that "incorrect" is sometimes 
subjective.

Keith

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

Re: Repetitions and consensus

[Joel Jaeggli]

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 published in 2007 
>>> with the catchy title "Inferring the Popularity of an Opinion From Its 
>>> Familiarity: A Repetitive Voice Can Sound Like a Chorus". 
>> 
>> We deal with that quite a bit. I can think of discussions in v6ops and on 
>> this list in which a single person contributed one message in four in a 200+ 
>> message thread, and although he was the lone speaker with that viewpoint, my 
>> co-chair told me he thought we lacked consensus.
> 
> 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 vigorously and to respond to numerous attacks on not only his 
> viewpoint but also his legitimacy, motivation, character, etc., there is a 
> tendency among some to dismiss his opinions even more.
> 
> All of these clearly happened in recent discussions in v6ops.
> 
> It's certainly true that one lone speaker should not be able to deny rough 
> consensus to a group.  That's why the consensus only has to be "rough".   But 
> if the group doesn't even try to understand a minority view, it cannot be 
> said to have tried to reach consensus of any kind.

Quite contrary imho if you want to speak of 6to4-to-historic in specific. The 
viewpoint most effusively expressed by yourself is quite well understood. Lack 
of reconciliation does not imply that it was simply swept under the rug.

>> 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, concurrence, accord, unity, unanimity, 
>> solidarity; formal concord") coupled with listening carefully to those who 
>> disagree and determining whether their arguments actually make sense and 
>> point up an issue. I will recognize a single person's point at issue if it 
>> appears that they are not being listened to or their issue dealt with. If 
>> they are simply hammering a point, and their point is incorrect, I will note 
>> that they have been hammering an incorrect point ("even though you are 
>> sending one email in four in a long thread and are expressing extreme 
>> concern about a draft because it does , I will overlook your objections 
>> because it doesn't do that.") and move on.
> 
> I'd agree with that logic.  Though I note that "incorrect" is sometimes 
> subjective.

I'd go a little further. It is trivially possible to establish two opposing 
positions neither of which are "wrong".

> Keith
> 
> ___
> 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: Repetitions and consensus

[Keith Moore]

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 vigorously and to respond to numerous attacks on not only his 
>> viewpoint but also his legitimacy, motivation, character, etc., there is a 
>> tendency among some to dismiss his opinions even more.
>> 
>> All of these clearly happened in recent discussions in v6ops.
>> 
>> It's certainly true that one lone speaker should not be able to deny rough 
>> consensus to a group.  That's why the consensus only has to be "rough".   
>> But if the group doesn't even try to understand a minority view, it cannot 
>> be said to have tried to reach consensus of any kind.
> 
> Quite contrary imho if you want to speak of 6to4-to-historic in specific. The 
> viewpoint most effusively expressed by yourself is quite well understood. 
> Lack of reconciliation does not imply that it was simply swept under the rug.

I have recently received several private emails that indicated that particular 
speakers did not understand it, though we were usually able to sort out the 
differences in private conversation.

I certainly don't claim that my concerns were swept under the rug by the WG 
management.  But in a group is largely composed of individuals with a 
particular point-of-view, it can be difficult for members of that group to see 
the merit in the opinion of a minority, or lone speaker, with a different 
point-of-view.  Those who want to categorically dismiss that minority viewpoint 
will get plenty of support from other members in the group.

>>> 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, concurrence, accord, unity, unanimity, 
>>> solidarity; formal concord") coupled with listening carefully to those who 
>>> disagree and determining whether their arguments actually make sense and 
>>> point up an issue. I will recognize a single person's point at issue if it 
>>> appears that they are not being listened to or their issue dealt with. If 
>>> they are simply hammering a point, and their point is incorrect, I will 
>>> note that they have been hammering an incorrect point ("even though you are 
>>> sending one email in four in a long thread and are expressing extreme 
>>> concern about a draft because it does , I will overlook your objections 
>>> because it doesn't do that.") and move on.
>> 
>> I'd agree with that logic.  Though I note that "incorrect" is sometimes 
>> subjective.
> 
> I'd go a little further. It is trivially possible to establish two opposing 
> positions neither of which are "wrong".

Absolutely.

Keith

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

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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 information exchanged between routing protocol 
instances, and to underlying protocols that may also need to be 
protected in specific circumstances.  Individual protocol analysis 
documents will need to be more specific in their usage.


work to address the issue?
Yours,
Joel

On 7/13/2011 2:47 PM, Wesley Eddy wrote:

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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.

Apparently, this does not address Joe's concern.



"message sent from one routing process to another" doesn't seem to be
right to me either since it sounds like the first definition that
covers routing protocol data only, and not underlying protocols, so I
wouldn't expect that proposal to address Joe's concern.


___
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

[John E Drake]

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>
> (ProactiveConnectivityVerification,   Continuity Check and
> Remote Defect
> indicationfor 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
> >
> _

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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:



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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are
exchanged?

 From the intro:
Four main steps were identified for that tightening:

o More secure mechanisms and practices for operating routers.
...

o Cleaning up the Internet Routing Registry repository [IRR],
...

o Specifications for cryptographic validation of routing message
content.
...

o Securing the routing protocols' packets on the wire

This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges.

So this document is clearly NOT about "the message from one routing
process to another (that would be 'routing message content', IMO). I.e.,
this doc focuses on securing the transfer mechanism NOT the message.

Thus this is the key to the entirety of the doc. This doc needs to be
very clear about what this is, at which point it can certainly also then
refer back to the original RFC (e.g., "this is referred to in RFC 4948
as 'on the wire'").

Joe




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

Re: notes from discussion of KARP design guidelines

[Joe Touch]

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 ways. In this document, it is used to refer
both to information exchanged between routing protocol instances, and to
underlying protocols that may also need to be protected in specific
circumstances.


I think that is in direct contrast to the current text in the intro, 
that appears to differentiate between the two and focus on the latter.


Joe


Individual protocol analysis documents will need to be
more specific in their usage.

work to address the issue?
Yours,
Joel

On 7/13/2011 2:47 PM, Wesley Eddy wrote:

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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.

Apparently, this does not address Joe's concern.



"message sent from one routing process to another" doesn't seem to be
right to me either since it sounds like the first definition that
covers routing protocol data only, and not underlying protocols, so I
wouldn't expect that proposal to address Joe's concern.


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

Re: notes from discussion of KARP design guidelines

[Joe Touch]

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.


The current scope is clear from the bullet list only by the assumption 
that (a) the bullets are mutually exclusive, and (b) since the "routing 
message content" is clear, it cannot be part of "on the wire".


I.e., it requires the reader interpret scope by a matter of deduction 
and exclusion, rather than stating it clearly and explicitly.


Joe



Yours,
Joel


On 7/13/2011 2:58 PM, Joe Touch wrote:



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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are
exchanged?

From the intro:
Four main steps were identified for that tightening:

o More secure mechanisms and practices for operating routers.
...

o Cleaning up the Internet Routing Registry repository [IRR],
...

o Specifications for cryptographic validation of routing message
content.
...

o Securing the routing protocols' packets on the wire

This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges.

So this document is clearly NOT about "the message from one routing
process to another (that would be 'routing message content', IMO). I.e.,
this doc focuses on securing the transfer mechanism NOT the message.

Thus this is the key to the entirety of the doc. This doc needs to be
very clear about what this is, at which point it can certainly also then
refer back to the original RFC (e.g., "this is referred to in RFC 4948
as 'on the wire'").

Joe




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

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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, is the validation of that information.  KARP is not assuring 
that the information is valid.  it is responsible to ensure that the 
message is not modified between the two peers.


Yes, this means that there is an overlap in protection between 
validation information and packet authentication information.  So?  The 
scope is very clear as to whose problem is whose.  (This is merely a 
statement of fact.  If we have path signing and TCP-AO, there are two 
sets of mechanisms preventing modification of some of the BGP 
information.)


The text after the bullet list explicitly says what part is in scope. 
it does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the 
introductory scoping material, I would be happy to look at it.


Yours,
Joel

On 7/13/2011 5:08 PM, Joe Touch wrote:

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.


The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the "routing
message content" is clear, it cannot be part of "on the wire".

I.e., it requires the reader interpret scope by a matter of deduction
and exclusion, rather than stating it clearly and explicitly.

Joe



Yours,
Joel


On 7/13/2011 2:58 PM, Joe Touch wrote:



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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are
exchanged?

From the intro:
Four main steps were identified for that tightening:

o More secure mechanisms and practices for operating routers.
...

o Cleaning up the Internet Routing Registry repository [IRR],
...

o Specifications for cryptographic validation of routing message
content.
...

o Securing the routing protocols' packets on the wire

This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges.

So this document is clearly NOT about "the message from one routing
process to another (that would be 'routing message content', IMO). I.e.,
this doc focuses on securing the transfer mechanism NOT the message.

Thus this is the key to the entirety of the doc. This doc needs to be
very clear about what this is, at which point it can certainly also then
refer back to the original RFC (e.g., "this is referred to in RFC 4948
as 'on the wire'").

Joe






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

Re: Second Last Call: (Web Host

[Peter Saint-Andre]

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 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)?
> 
> How about publishing as Informational?
> 
> RFC 2026 says:
> 
>4.  THE INTERNET STANDARDS TRACK
> 
>Specifications that are intended to become Internet Standards evolve
>through a set of maturity levels known as the "standards track".
>These maturity levels -- "Proposed Standard", "Draft Standard", and
>"Standard" -- are defined and discussed in section 4.1.
> 
> If there is no strong consensus and commitment to work the document
> along the standards track up to full standard, then it shouldn't
> be on the standards track at all.

Who said there isn't strong consensus and commitment to work the
document along the standards track? The only statement I've seen is that
it's not a generic solution for all metadata problems.

> For documents where the only purpose of publishing it is only to obtain
> an rfc number for it, but otherwise just describe "this is how others
> have solved a particular problem before" and let vendors and implementors
> wiggle out interop, then Informational is quite appropriate.

I see no reason to make those assumptions here.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


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

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

[Peter Saint-Andre]

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 the authors. I just want to make sure that there's a good
reason to change it from Standards Track to Informational. IMHO "this
document doesn't solve the problem in the most generic way" would
prevent us from publishing a rather large number of specifications on
the Standards Track. There's nothing evil about scoping a document so
that it solves a more particular problem.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


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

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

[John E Drake]

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; IETF-Announce
> Cc: m...@ietf.org
> Subject: R: RE: [mpls] R: RE: R: Re: Last Call:  cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check
> and Remote Defect indication for MPLS Transport Profile) to Proposed
> Standard
> 
> The JWT report is aligned with my statement.

JD:  As SG15 management is fond of pointing out, when it suits them, the JWT 
operated on a very compressed time scale and didn't fully explore all of the 
technical issues

> 
> 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).

JD:  I'm not sure what your point is

> 
> 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.

JD:  Obviously we disagree

> 
> 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.

JD:  The requirements as documented in RFCs 5654, 5860, and 5951, or the 
requirements that seem to change based upon the phases of the moon?
 
> 
> >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" annou...@ietf.org>
> >Cc: "m...@ietf.org"
> >Ogg: RE: [mpls] R: RE: R: Re:LastCall:    cc-cv-rdi-05.
> txt>   (Proactive  ConnectivityVerification,   Continuity
> Check and Remote
> Defectindication  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:  rdi-
> >> 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 f

Re: Confidentiality notices on email messages

[John C Klensin]

--On Wednesday, July 13, 2011 09:38 -0700 Marc Petit-Huguenin
 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.
>...

What did you have in mind?  Something like

  Content-type: text/legal-noise; charset=...

or perhaps

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

:-(

john



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

Re: Confidentiality notices on email messages

[Dave Cridland]

On Wed Jul 13 23:19:00 2011, John C Klensin wrote:



--On Wednesday, July 13, 2011 09:38 -0700 Marc Petit-Huguenin
 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.
>...

What did you have in mind?  Something like

  Content-type: text/legal-noise; charset=...


text/legal-noise+xml, obviously.

Only XML is sufficiently verbose for lawyers.

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Marc Petit-Huguenin]

-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
>  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.
>> ...
> 
> What did you have in mind?  Something like
> 
>   Content-type: text/legal-noise; charset=...
> 
> or perhaps
> 
>   Content-type: text/noise; noise-type="bogus-legal-disclaimer",
> charset=...
> 
> :-(
> 

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

- -- 
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)

iEYEARECAAYFAk4eINwACgkQ9RoMZyVa61d2ugCfaPniSosAr3MXqnZQzzFG2PC/
j0MAoJqZ2gYeOHZNBRh0pf0VrJCsvZam
=6Z3z
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[Martin Rex]

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 admonished 
> not to slap a "confidential" label on anything automatically or 
> without consideration, because, we were warned, doing so can cause 
> the label to lose meaning for everything.  In other words, if we 
> labelled everything "confidential," then we were really saying 
> nothing was confidential.

Congratulation for having met a lawyer with a clue in law.
This assessment is definitely valid for Germany.


> 
> 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.

These notices are often suggested by real lawyers.

But it is hard to determine whether they are from the simple
clueless type, or whether they know that this notice is bogus, but
also know that there are many clueless folks, clueless other lawyers
and clueless judges out there that will fall for it, therefore
providing some small value in probabilistic terms. 


-Martin

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

Re: notes from discussion of KARP design guidelines

[Joe Touch]

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, and which the text says is not part of
the scope, is the validation of that information. KARP is not assuring
that the information is valid. it is responsible to ensure that the
message is not modified between the two peers.

Yes, this means that there is an overlap in protection between
validation information and packet authentication information.So? The
scope is very clear as to whose problem is whose.


That makes absolutely no sense. If there's overlap, then it's obviously 
unclear as to whose problem is whose.



(This is merely a
statement of fact. If we have path signing and TCP-AO, there are two
sets of mechanisms preventing modification of some of the BGP information.)


I appreciate that different layers can include redundant protections. 
However, I'm trying to understand what is *expected* from each layer.



The text after the bullet list explicitly says what part is in scope. it
does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.


Glad to, with a bit more context.

Can you please define what is being validated in the third bullet that 
is NOT protected by the last one or vice versa? AFAICT, it would be:


#3 is entirely responsible for ensuring that a source has permission to 
advertise a particular route


#3 or #4 could confirm the identity of the source of a piece of 
information (#3 is required if transitive, #4 works only if directly 
communicated).


#3 or #4 could confirm the integrity of such information

#4 is required to protect the properties of lower layers insofar as they 
are used as such information to the routing protocol (e.g., BGP tossing 
out routes because TCP connections fail).


If this is the case, then I understand 4 as protecting the *channel* 
over which routing messages are exchanged (which ends up protecting the 
messages too), and 3 as focusing on the routing layer messages themselves.


Is that the case?

Joe




On 7/13/2011 5:08 PM, Joe Touch wrote:

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.


The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the "routing
message content" is clear, it cannot be part of "on the wire".

I.e., it requires the reader interpret scope by a matter of deduction
and exclusion, rather than stating it clearly and explicitly.

Joe



Yours,
Joel


On 7/13/2011 2:58 PM, Joe Touch wrote:



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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are
exchanged?

From the intro:
Four main steps were identified for that tightening:

o More secure mechanisms and practices for operating routers.
...

o Cleaning up the Internet Routing Registry repository [IRR],
...

o Specifications for cryptographic validation of routing message
content.
...

o Securing the routing protocols' packets on the wire

This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges.

So this document is clearly NOT about "the message from one routing
process to another (that would be 'routing message content', IMO).
I.e.,
this doc focuses on securing the transfer mechanism NOT the message.

Thus this is the key to the entirety of the doc. This doc needs to be
very clear about what this is, at which point it can certainly also
then
refer back to the original RFC (e.g., "this is referred to in RFC 4948
as 'on the wire'").

Joe






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

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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 discarded.)  (I would have said that more simply, but I have been 
beat up by security folks for descriing what authentication does too 
simply.)  It is also concerned that the receiver be able to correctly 
tell who sent the message, or discard the message.


(Which layer those determinations are made at varies across the 
protocols, and is something we were trying not to get detailed about in 
the design guidelines document.)


Sent and received refer to inforamtion being exchanged between directly 
communicating IP routers.  (Of course, directly depends upon the 
protocol and configuration, as both targetted LDP and remote BGP the two 
parties are directly communicating through other routers.)


This document is NOT supposed to be the framework document for the KARP 
work.  The working group did not have enough energy to produce that, and 
I would therefore not want to turn this into a full-blown framework 
document.
With that understanding, if there is an extra paragraph that will help 
the introduction be clear about this, please send text.


Yours,
Joel

On 7/13/2011 7:02 PM, Joe Touch wrote:

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, and which the text says is not part of
the scope, is the validation of that information. KARP is not assuring
that the information is valid. it is responsible to ensure that the
message is not modified between the two peers.

Yes, this means that there is an overlap in protection between
validation information and packet authentication information.So? The
scope is very clear as to whose problem is whose.


That makes absolutely no sense. If there's overlap, then it's obviously
unclear as to whose problem is whose.


(This is merely a
statement of fact. If we have path signing and TCP-AO, there are two
sets of mechanisms preventing modification of some of the BGP
information.)


I appreciate that different layers can include redundant protections.
However, I'm trying to understand what is *expected* from each layer.


The text after the bullet list explicitly says what part is in scope. it
does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.


Glad to, with a bit more context.

Can you please define what is being validated in the third bullet that
is NOT protected by the last one or vice versa? AFAICT, it would be:

#3 is entirely responsible for ensuring that a source has permission to
advertise a particular route

#3 or #4 could confirm the identity of the source of a piece of
information (#3 is required if transitive, #4 works only if directly
communicated).

#3 or #4 could confirm the integrity of such information

#4 is required to protect the properties of lower layers insofar as they
are used as such information to the routing protocol (e.g., BGP tossing
out routes because TCP connections fail).

If this is the case, then I understand 4 as protecting the *channel*
over which routing messages are exchanged (which ends up protecting the
messages too), and 3 as focusing on the routing layer messages themselves.

Is that the case?

Joe




On 7/13/2011 5:08 PM, Joe Touch wrote:

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.


The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the "routing
message content" is clear, it cannot be part of "on the wire".

I.e., it requires the reader interpret scope by a matter of deduction
and exclusion, rather than stating it clearly and explicitly.

Joe



Yours,
Joel


On 7/13/2011 2:58 PM, Joe Touch wrote:



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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over whi

Re: notes from discussion of KARP design guidelines

[Joe Touch]

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 information sent, or recognizably NOT the information sent (so it
can be discarded.) (I would have said that more simply, but I have been
beat up by security folks for describing what authentication does too
simply.) It is also concerned that the receiver be able to correctly
tell who sent the message, or discard the message.

(Which layer those determinations are made at varies across the
protocols, and is something we were trying not to get detailed about in
the design guidelines document.)

Sent and received refer to inforamtion being exchanged between directly
communicating IP routers. (Of course, directly depends upon the protocol
and configuration, as both targetted LDP and remote BGP the two parties
are directly communicating through other routers.)


OK - so that's protecting the information exchanged between two routers.

I would argue that it also presumes protecting such information whether 
it's explicit at the routing layer (e.g., BGP path messages), other 
headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the 
routing protocol), and the semantics of other layers of protocols (e.g., 
whether a connection remains "up", as with TCP or PPTP).



This document is NOT supposed to be the framework document for the KARP
work. The working group did not have enough energy to produce that, and
I would therefore not want to turn this into a full-blown framework
document.
With that understanding, if there is an extra paragraph that will help
the introduction be clear about this, please send text.


If we agree on the above, then I can proceed to document suggested 
changes and the paragraph.


Joe



Yours,
Joel

On 7/13/2011 7:02 PM, Joe Touch wrote:

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, and which the text says is not part of
the scope, is the validation of that information. KARP is not assuring
that the information is valid. it is responsible to ensure that the
message is not modified between the two peers.

Yes, this means that there is an overlap in protection between
validation information and packet authentication information.So? The
scope is very clear as to whose problem is whose.


That makes absolutely no sense. If there's overlap, then it's obviously
unclear as to whose problem is whose.


(This is merely a
statement of fact. If we have path signing and TCP-AO, there are two
sets of mechanisms preventing modification of some of the BGP
information.)


I appreciate that different layers can include redundant protections.
However, I'm trying to understand what is *expected* from each layer.


The text after the bullet list explicitly says what part is in scope. it
does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.


Glad to, with a bit more context.

Can you please define what is being validated in the third bullet that
is NOT protected by the last one or vice versa? AFAICT, it would be:

#3 is entirely responsible for ensuring that a source has permission to
advertise a particular route

#3 or #4 could confirm the identity of the source of a piece of
information (#3 is required if transitive, #4 works only if directly
communicated).

#3 or #4 could confirm the integrity of such information

#4 is required to protect the properties of lower layers insofar as they
are used as such information to the routing protocol (e.g., BGP tossing
out routes because TCP connections fail).

If this is the case, then I understand 4 as protecting the *channel*
over which routing messages are exchanged (which ends up protecting the
messages too), and 3 as focusing on the routing layer messages
themselves.

Is that the case?

Joe




On 7/13/2011 5:08 PM, Joe Touch wrote:

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.


The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the "routing
message content" is clear, it cannot be part of "on the wire".

I.e., it requires the reader interpret scope by a matter of deduction
and exclusion, rather than stating it clearly and explicitly.

Joe



Yours,
Joel


On

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

There may be a confusion of objectives.
The WG and chairs do not expect the design guidelines document to 
achieve a degree of thoroughness such taht if one checks every item in 
there, and nothing else, then one will be able to do a complete analysis 
of a routing protocol.
Rather, it is intended to provide assistance and a starting point for 
that analysis.  Folks writing analysis documents are expected to bring 
security and routing protocol skills to the table, and to make sure they 
spot all the issues.


Yours,
Joel

On 7/13/2011 7:02 PM, Joe Touch wrote:

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, and which the text says is not part of
the scope, is the validation of that information. KARP is not assuring
that the information is valid. it is responsible to ensure that the
message is not modified between the two peers.

Yes, this means that there is an overlap in protection between
validation information and packet authentication information.So? The
scope is very clear as to whose problem is whose.


That makes absolutely no sense. If there's overlap, then it's obviously
unclear as to whose problem is whose.


(This is merely a
statement of fact. If we have path signing and TCP-AO, there are two
sets of mechanisms preventing modification of some of the BGP
information.)


I appreciate that different layers can include redundant protections.
However, I'm trying to understand what is *expected* from each layer.


The text after the bullet list explicitly says what part is in scope. it
does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.


Glad to, with a bit more context.

Can you please define what is being validated in the third bullet that
is NOT protected by the last one or vice versa? AFAICT, it would be:

#3 is entirely responsible for ensuring that a source has permission to
advertise a particular route

#3 or #4 could confirm the identity of the source of a piece of
information (#3 is required if transitive, #4 works only if directly
communicated).

#3 or #4 could confirm the integrity of such information

#4 is required to protect the properties of lower layers insofar as they
are used as such information to the routing protocol (e.g., BGP tossing
out routes because TCP connections fail).

If this is the case, then I understand 4 as protecting the *channel*
over which routing messages are exchanged (which ends up protecting the
messages too), and 3 as focusing on the routing layer messages themselves.

Is that the case?

Joe




On 7/13/2011 5:08 PM, Joe Touch wrote:

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.


The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the "routing
message content" is clear, it cannot be part of "on the wire".

I.e., it requires the reader interpret scope by a matter of deduction
and exclusion, rather than stating it clearly and explicitly.

Joe



Yours,
Joel


On 7/13/2011 2:58 PM, Joe Touch wrote:



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 would also state for clarity that in this
document it is used to refer to the message sent from one routing
process to another.


Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are
exchanged?

From the intro:
Four main steps were identified for that tightening:

o More secure mechanisms and practices for operating routers.
...

o Cleaning up the Internet Routing Registry repository [IRR],
...

o Specifications for cryptographic validation of routing message
content.
...

o Securing the routing protocols' packets on the wire

This document addresses the last bullet, securing the packets on the
wire of the routing protocol exchanges.

So this document is clearly NOT about "the message from one routing
process to another (that would be 'routing message content', IMO).
I.e.,
this doc focuses on securing the transfer mechanism NOT the message.

Thus this is the key to the entirety of the doc. This doc needs to be
very clear about what this is, at which point it can certainly also
then
refe

Re: notes from discussion of KARP design guidelines

[Joel M. Halpern]

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 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 information sent, or recognizably NOT the information sent (so it
can be discarded.) (I would have said that more simply, but I have been
beat up by security folks for describing what authentication does too
simply.) It is also concerned that the receiver be able to correctly
tell who sent the message, or discard the message.

(Which layer those determinations are made at varies across the
protocols, and is something we were trying not to get detailed about in
the design guidelines document.)

Sent and received refer to inforamtion being exchanged between directly
communicating IP routers. (Of course, directly depends upon the protocol
and configuration, as both targetted LDP and remote BGP the two parties
are directly communicating through other routers.)


OK - so that's protecting the information exchanged between two routers.

I would argue that it also presumes protecting such information whether
it's explicit at the routing layer (e.g., BGP path messages), other
headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the
routing protocol), and the semantics of other layers of protocols (e.g.,
whether a connection remains "up", as with TCP or PPTP).


This document is NOT supposed to be the framework document for the KARP
work. The working group did not have enough energy to produce that, and
I would therefore not want to turn this into a full-blown framework
document.
With that understanding, if there is an extra paragraph that will help
the introduction be clear about this, please send text.


If we agree on the above, then I can proceed to document suggested
changes and the paragraph.

Joe



Yours,
Joel

On 7/13/2011 7:02 PM, Joe Touch wrote:

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, and which the text says is not part of
the scope, is the validation of that information. KARP is not assuring
that the information is valid. it is responsible to ensure that the
message is not modified between the two peers.

Yes, this means that there is an overlap in protection between
validation information and packet authentication information.So? The
scope is very clear as to whose problem is whose.


That makes absolutely no sense. If there's overlap, then it's obviously
unclear as to whose problem is whose.


(This is merely a
statement of fact. If we have path signing and TCP-AO, there are two
sets of mechanisms preventing modification of some of the BGP
information.)


I appreciate that different layers can include redundant protections.
However, I'm trying to understand what is *expected* from each layer.


The text after the bullet list explicitly says what part is in
scope. it
does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.


Glad to, with a bit more context.

Can you please define what is being validated in the third bullet that
is NOT protected by the last one or vice versa? AFAICT, it would be:

#3 is entirely responsible for ensuring that a source has permission to
advertise a particular route

#3 or #4 could confirm the identity of the source of a piece of
information (#3 is required if transitive, #4 works only if directly
communicated).

#3 or #4 could confirm the integrity of such information

#4 is required to protect the properties of lower layers insofar as they
are used as such information to the routing protocol (e.g., BGP tossing
out routes because TCP connections fail).

If this is the case, then I understand 4 as protecting the *channel*
over which routing messages are exchanged (which ends up protecting the
messages too), and 3 as focusing on the routing layer messages
themselves.

Is that the case?

Joe




On 7/13/2011 5:08 PM, Joe Touch wrote:

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.


The current scope is clear from the bullet list only by the assumption
that (a) the bullets are mutually exclusive, and (b) since the
"routing
message content" is clear, it cannot be part of

Re: Confidentiality notices on email messages

[John Levine]

>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:

  http://jl.ly/Internet/confid.html

At least in the US, which is where the IETF has its formal existence,
these notices have no legal merit at all.  They're just stupid.

R's,
John

PS: Anyone who wants to argue they're not stupid should include citations
to case law.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confidentiality notices on email messages

[John Levine]

>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.

R's,
John

PS: Perhaps I should propose a revised RFC 5617 adding dkim=confidential.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Confidentiality notices on email messages

[Michel Py]

> 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 disclaimers. Although it's easy to configure
when using Outlook (using a signature), there was no disclaimer sent
when using the HTTP interface or the phones. They're not smart^H^H^H^H^H
technical enough to figure how to edit the "Sent from my Iphone" string,
either.

So, I sold and installed a commercial product:
http://www.exclaimer.com/products/mail-disclaimers/Default.aspx

ROTFL. Thanks John, you made my day. Hey, someone has to make a living
out of this BS, might as well be me.

Michel.

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

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

[GT RAMIREZ, Medel G.]

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; IETF-Announce; ietf@ietf.org
Subject: Re: [mpls] R: RE: R: Re: LastCall:
 (Proactive Connectivity
Verification, Continuity Check and Remote Defect indicationfor MPLS
Transport Profile) to Proposed Standard

 

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
 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

 

This e-mail message (including attachments, if any) is intended for the use of 
the individual or the entity to whom it is addressed and may contain 
information that is privileged, proprietary, confidential and exempt from 
disclosure. If you are not the intended recipient, you are notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify the 
sender and delete this E-mail message immediately.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf