date:20110713

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

2011-07-13 Thread 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


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

2011-07-13 Thread 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

2011-07-13 Thread 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

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

2011-07-13 Thread 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




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

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

2011-07-13 Thread 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

2011-07-13 Thread 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

2011-07-13 Thread 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


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: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed St

2011-07-13 Thread 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: draft-ietf-mpls-tp-cc-cv-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 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.iterminio.ottone...@libero.it,
 rco...@ptinovacao.ptrco...@ptinovacao.pt,
 ietf@ietf.orgietf@ietf.org,
 IETF-Announceietf-annou...@ietf.org
 Cc: m...@ietf.orgm...@ietf.org
 Ogg: RE: [mpls] R: Re: Last  Call:   lt;draft-ietf-mpls-tp-cc-cv-rdi-
 05.txtgt;
 (ProactiveConnectivityVerification,   Continuity Check and
 Remote Defect
 indicationfor MPLSTransport   Profile) to Proposed Standard
 
 Hi Erminio:
 
 snipped
 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


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


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


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


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: draft-hammer-hostmeta-16.txt (Web Host

2011-07-13 Thread 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: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback

2011-07-13 Thread 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: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Propose

2011-07-13 Thread 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: draft-ietf-mpls-tp-cc-
 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.iterminio.ottone...@libero.it,
 david.i.
 al...@ericsson.comdavid.i.al...@ericsson.com, rco...@ptinovacao.pt
 rco...@ptinovacao.pt, ietf@ietf.orgietf@ietf.org, IETF-
 Announceietf-
 annou...@ietf.org
 Cc: m...@ietf.orgm...@ietf.org
 Ogg: RE: [mpls] R: RE: R: Re:LastCall:   lt;draft-ietf-mpls-tp-
 cc-cv-rdi-05.
 txtgt;   (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: draft-ietf-mpls-tp-cc-cv-
 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 front, and IMO why when the IETF started down

Re: Confidentiality notices on email messages

2011-07-13 Thread John C Klensin



--On Wednesday, July 13, 2011 09:38 -0700 Marc Petit-Huguenin
petit...@acm.org wrote:

...
 Yes, and perhaps disclaimers/confidentiality notices should be
 standardized with their own MIME type to make automatic
 processing easier so receivers of this kind of notice
 (mailing-list or other) can 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

2011-07-13 Thread 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
 petit...@acm.org wrote:
 
 ...
 Yes, and perhaps disclaimers/confidentiality notices should be
 standardized with their own MIME type to make automatic
 processing easier so receivers of this kind of notice
 (mailing-list or other) can 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

2011-07-13 Thread 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


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


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 which

Re: notes from discussion of KARP design guidelines


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

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 on

Re: Confidentiality notices on email messages

2011-07-13 Thread 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

2011-07-13 Thread 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

2011-07-13 Thread 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: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indicationfor MPLS Transport Profile) to Proposed Stan

2011-07-13 Thread 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:
draft-ietf-mpls-tp-cc-cv-rdi-05.txt (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
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: erminio.ottone...@libero.it, rco...@ptinovacao.pt,
ietf@ietf.org,

IETF-Announceietf-annou...@ietf.org

Cc: m...@ietf.org
Ogg: RE: [mpls] R: Re: LastCall:
lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt;

(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

IETF 81 - Early Bird Cut-off Friday, 15 July 2011

2011-07-13 Thread IETF Secretariat

81st IETF Meeting
Quebec City, Canada
July 24 - 29, 2011
Host: Research In Motion (RIM)

Register online at: http://www.ietf.org/meetings/81/

Registration - Early Bird Cut-off is July 15, 2011
Early-Bird: $650 USD, if paid in full prior to 1700 PDT July 15.
Late: $800 USD if paid after Early-Bird cutoff date and time. 
Register online at:
http://www.ietf.org/meetings/81/

Only 11 days until the Quebec City IETF!
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Document Action: 'Design Considerations for Session Initiation Protocol (SIP) Overload Control' to Informational RFC (draft-ietf-soc-overload-design-08.txt)

2011-07-13 Thread The IESG

The IESG has approved the following document:
- 'Design Considerations for Session Initiation Protocol (SIP) Overload
   Control'
  (draft-ietf-soc-overload-design-08.txt) as an Informational RFC

This document is the product of the SIP Overload Control Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/




Technical Summary

   Overload occurs in Session Initiation Protocol (SIP) networks when
   SIP servers have insufficient resources to handle all SIP messages
   they receive.  Even though the SIP protocol provides a limited
   overload control mechanism through its 503 (Service Unavailable)
   response code, SIP servers are still vulnerable to overload.  This
   document discusses models and design considerations for a SIP
   overload control mechanism.

Working Group Summary

  This document was originally started by an ad-hoc Design Team within the 
SIPPING wg.
  The document was then adopted by the SIP  Overload Control WG once it has 
been created.

Document Quality

  The draft is a design considerations document and therefore there are no 
implementations.
  There are implementations of drafts that are based on the design 
considerations draft.
  The document was reviewed in an early stage by the transport area.
  Version 04 of the draft has also received a second review by Pasi Lassila, an
  expert on control theory at Aalto university (in Finland) identified by Lars 
Eggert.

Personnel

  Salvatore Loreto is the Document Shepherd
  Robert Sparks is the Responsible RAI AD
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC Series Editor Search Announcement

2011-07-13 Thread RSOC Chair

The Internet Engineering Task Force is seeking an RFC Series Editor (RSE).  The 
RSE has overall responsibility 
for the quality, continuity, and evolution of the Request for Comments (RFC) 
Series, the Internet's seminal 
technical standards and publications series.  The position has operational and 
policy development responsibilities.

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

The following qualifications are desired: 

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

More information about the position can be found at 
http://www.rfc-editor.org/rse/RSE-position.html.

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

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

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

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

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

RFC 6131 on Sieve Vacation Extension: Seconds Parameter


A new Request for Comments is now available in online RFC libraries.


RFC 6131

Title:  Sieve Vacation Extension: Seconds Parameter 
Author: R. George, B. Leiba
Status: Standards Track
Stream: IETF
Date:   July 2011
Mailbox:robin...@gmail.com, 
barryle...@computer.org
Pages:  5
Characters: 9407
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-sieve-vacation-seconds-03.txt

URL:http://www.rfc-editor.org/rfc/rfc6131.txt

This document describes a further extension to the Sieve Vacation
extension, allowing multiple auto-replies to the same sender in a
single day by adding a :seconds parameter.  [STANDARDS-TRACK]

This document is a product of the Sieve Mail Filtering Language Working Group 
of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6132 on Sieve Notification Using Presence Information


A new Request for Comments is now available in online RFC libraries.


RFC 6132

Title:  Sieve Notification Using Presence Information 
Author: R. George, B. Leiba
Status: Standards Track
Stream: IETF
Date:   July 2011
Mailbox:robin...@gmail.com, 
barryle...@computer.org
Pages:  8
Characters: 17677
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-sieve-notify-presence-04.txt

URL:http://www.rfc-editor.org/rfc/rfc6132.txt

This is a further extension to the Sieve mail filtering language
Notification extension, defining presence information that may be
checked through the notify_method_capability feature.  [STANDARDS-TRACK]

This document is a product of the Sieve Mail Filtering Language Working Group 
of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6133 on Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality


A new Request for Comments is now available in online RFC libraries.


RFC 6133

Title:  Sieve Email Filtering: Use of 
Presence Information with Auto-Responder Functionality 
Author: R. George, B. Leiba,
A. Melnikov
Status: Informational
Stream: IETF
Date:   July 2011
Mailbox:robin...@gmail.com, 
barryle...@computer.org, 
alexey.melni...@isode.com
Pages:  9
Characters: 17652
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-sieve-autoreply-04.txt

URL:http://www.rfc-editor.org/rfc/rfc6133.txt

This document describes how the Sieve email filtering language, along
with some extensions, can be used to create automatic replies to
incoming electronic mail messages based on the address book and
presence information of the recipient.  This document is not an 
Internet Standards Track specification; it is published for 
informational purposes.

This document is a product of the Sieve Mail Filtering Language Working Group 
of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6134 on Sieve Extension: Externally Stored Lists


A new Request for Comments is now available in online RFC libraries.


RFC 6134

Title:  Sieve Extension: Externally Stored Lists 
Author: A. Melnikov, B. Leiba
Status: Standards Track
Stream: IETF
Date:   July 2011
Mailbox:alexey.melni...@isode.com, 
barryle...@computer.org
Pages:  18
Characters: 37379
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-sieve-external-lists-10.txt

URL:http://www.rfc-editor.org/rfc/rfc6134.txt

The Sieve email filtering language can be used to implement email
whitelisting, blacklisting, personal distribution lists, and other
sorts of list matching.  Currently, this requires that all members of
such lists be hard-coded in the script itself.  Whenever a member of
a list is added or deleted, the script needs to be updated and
possibly uploaded to a mail server.

This document defines a Sieve extension for accessing externally
stored lists -- lists whose members are stored externally to the
script, such as using the Lightweight Directory Access Protocol
(LDAP), the Application Configuration Access Protocol (ACAP), vCard
Extensions to WebDAV (CardDAV), or relational databases.  
[STANDARDS-TRACK]

This document is a product of the Sieve Mail Filtering Language Working Group 
of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

BCP 163, RFC 6303 on Locally Served DNS Zones


A new Request for Comments is now available in online RFC libraries.

BCP 163
RFC 6303

Title:  Locally Served DNS Zones 
Author: M. Andrews
Status: Best Current Practice
Stream: IETF
Date:   July 2011
Mailbox:ma...@isc.org
Pages:  10
Characters: 22503
See Also:   BCP0163

I-D Tag:draft-ietf-dnsop-default-local-zones-15.txt

URL:http://www.rfc-editor.org/rfc/rfc6303.txt

Experience with the Domain Name System (DNS) has shown that there are
a number of DNS zones that all iterative resolvers and recursive
nameservers should automatically serve, unless configured otherwise.
RFC 4193 specifies that this should occur for D.F.IP6.ARPA.  This
document extends the practice to cover the IN-ADDR.ARPA zones for RFC
1918 address space and other well-known zones with similar
characteristics.  This memo documents an Internet Best Current Practice.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6304 on AS112 Nameserver Operations


A new Request for Comments is now available in online RFC libraries.


RFC 6304

Title:  AS112 Nameserver Operations 
Author: J. Abley, W. Maton
Status: Informational
Stream: IETF
Date:   July 2011
Mailbox:joe.ab...@icann.org, 
wma...@ryouko.imsb.nrc.ca
Pages:  18
Characters: 34002
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dnsop-as112-ops-09.txt

URL:http://www.rfc-editor.org/rfc/rfc6304.txt

Many sites connected to the Internet make use of IPv4 addresses that
are not globally unique.  Examples are the addresses designated in
RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name
System (DNS) queries (so-called reverse lookups) corresponding to
those private-use addresses.  Since the addresses concerned have only
local significance, it is good practice for site administrators to
ensure that such queries are answered locally.  However, it is not
uncommon for such queries to follow the normal delegation path in the
public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to
such queries.  In addition, due to the wide deployment of private-use
addresses and the continuing growth of the Internet, the volume of
such queries is large and growing.  The AS112 project aims to provide
a distributed sink for such queries in order to reduce the load on
the IN-ADDR.ARPA authoritative servers.  The AS112 project is named
after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112
node and offers advice relating to such a node's operation.  This 
document is not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6305 on I'm Being Attacked by PRISONER.IANA.ORG!


A new Request for Comments is now available in online RFC libraries.


RFC 6305

Title:  I'm Being Attacked by PRISONER.IANA.ORG! 
Author: J. Abley, W. Maton
Status: Informational
Stream: IETF
Date:   July 2011
Mailbox:joe.ab...@icann.org, 
wma...@ryouko.imsb.nrc.ca
Pages:  8
Characters: 15287
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dnsop-as112-under-attack-help-help-06.txt

URL:http://www.rfc-editor.org/rfc/rfc6305.txt

Many sites connected to the Internet make use of IPv4 addresses that
are not globally unique.  Examples are the addresses designated in
RFC 1918 for private use within individual sites.

Hosts should never normally send DNS reverse-mapping queries for
those addresses on the public Internet.  However, such queries are
frequently observed.  Authoritative servers are deployed to provide
authoritative answers to such queries as part of a loosely
coordinated effort known as the AS112 project.

Since queries sent to AS112 servers are usually not intentional, the
replies received back from those servers are typically unexpected.
Unexpected inbound traffic can trigger alarms on intrusion detection
systems and firewalls, and operators of such systems often mistakenly
believe that they are being attacked.

This document provides background information and technical advice to
those firewall operators.  This document is not an Internet Standards Track 
specification; it is published for informational purposes.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6311 on Protocol Support for High Availability of IKEv2/IPsec


A new Request for Comments is now available in online RFC libraries.


RFC 6311

Title:  Protocol Support for High Availability 
of IKEv2/IPsec 
Author: R. Singh, Ed.,
G. Kalyani, Y. Nir,
Y. Sheffer, D. Zhang
Status: Standards Track
Stream: IETF
Date:   July 2011
Mailbox:r...@cisco.com, 
kagar...@cisco.com, 
y...@checkpoint.com,  
yaronf.i...@gmail.com, 
zhangdach...@huawei.com
Pages:  26
Characters: 58672
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ipsecme-ipsecha-protocol-06.txt

URL:http://www.rfc-editor.org/rfc/rfc6311.txt

The IPsec protocol suite is widely used for business-critical network
traffic.  In order to make IPsec deployments highly available, more
scalable, and failure-resistant, they are often implemented as IPsec
High Availability (HA) clusters.  However, there are many issues in
IPsec HA clustering, and in particular in Internet Key Exchange
Protocol version 2 (IKEv2) clustering.  An earlier document, IPsec
Cluster Problem Statement, enumerates the issues encountered in the
IKEv2/IPsec HA cluster environment.  This document resolves these
issues with the least possible change to the protocol.

This document defines an extension to the IKEv2 protocol to solve the
main issues of IPsec Cluster Problem Statement in the commonly
deployed hot standby cluster, and provides implementation advice for
other issues.  The main issues solved are the synchronization of
IKEv2 Message ID counters, and of IPsec replay counters.  [STANDARDS-TRACK]

This document is a product of the IP Security Maintenance and Extensions 
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6276 on DHCPv6 Prefix Delegation for Network Mobility (NEMO)


A new Request for Comments is now available in online RFC libraries.


RFC 6276

Title:  DHCPv6 Prefix Delegation for Network 
Mobility (NEMO) 
Author: R. Droms, P. Thubert,
F. Dupont, W. Haddad,
C. Bernardos
Status: Standards Track
Stream: IETF
Date:   July 2011
Mailbox:rdr...@cisco.com, 
pthub...@cisco.com, 
fdup...@isc.org,  
wassim.had...@ericsson.com, 
c...@it.uc3m.es
Pages:  14
Characters: 30430
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-mext-nemo-pd-07.txt

URL:http://www.rfc-editor.org/rfc/rfc6276.txt

One aspect of network mobility support is the assignment of a prefix
or prefixes to a mobile router for use on the links in the mobile
network.  This document specifies how DHCPv6 prefix delegation can be
used for this configuration task.  The mobile router plays the role
of requesting router, while the home agent assumes the role of
delegating router.  When the mobile router is outside its home
network, the mobile router also assumes the role of DHCPv6 relay
agent, co-located with the requesting router function.  
[STANDARDS-TRACK]

This document is a product of the Mobility EXTensions for IPv6 Working Group of 
the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 6322 on Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams