Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 88 messages in the last 7 days.
 
script run at: Fri Mar  4 00:53:02 EST 2011
 
Messages   |  Bytes| Who
+--++--+
  7.95% |7 |  6.82% |37672 | sh...@isc.org
  4.55% |4 |  5.22% |28851 | evniki...@gmail.com
  4.55% |4 |  4.51% |24918 | brian.e.carpen...@gmail.com
  4.55% |4 |  3.95% |21821 | bob.hin...@gmail.com
  4.55% |4 |  3.64% |20084 | d...@dcrocker.net
  2.27% |2 |  5.16% |28513 | stpe...@stpeter.im
  2.27% |2 |  4.50% |24861 | flu...@cisco.com
  3.41% |3 |  3.02% |16703 | julian.resc...@gmx.de
  3.41% |3 |  2.74% |15128 | hous...@vigilsec.com
  3.41% |3 |  2.54% |14052 | y...@checkpoint.com
  3.41% |3 |  2.54% |14015 | a...@shinkuro.com
  2.27% |2 |  2.64% |14569 | j...@joelhalpern.com
  1.14% |1 |  3.63% |20053 | bernard_ab...@hotmail.com
  1.14% |1 |  3.21% |17701 | rstruik@gmail.com
  2.27% |2 |  1.96% |10843 | chell...@pobox.com
  2.27% |2 |  1.92% |10592 | barryle...@computer.org
  2.27% |2 |  1.69% | 9353 | bortzme...@nic.fr
  1.14% |1 |  2.07% |11404 | anthonybr...@gmail.com
  1.14% |1 |  1.41% | 7766 | wo...@isc.org
  1.14% |1 |  1.39% | 7673 | john-i...@jck.com
  1.14% |1 |  1.34% | 7391 | a...@nostrum.com
  1.14% |1 |  1.30% | 7199 | rkoo...@cisco.com
  1.14% |1 |  1.28% | 7061 | rja.li...@gmail.com
  1.14% |1 |  1.28% | 7051 | daedu...@btconnect.com
  1.14% |1 |  1.26% | 6962 | nar...@us.ibm.com
  1.14% |1 |  1.24% | 6827 | lly...@civil-tongue.net
  1.14% |1 |  1.20% | 6627 | nurit.sprec...@nsn.com
  1.14% |1 |  1.16% | 6433 | h...@ripe.net
  1.14% |1 |  1.15% | 6355 | kanno.sat...@po.ntts.co.jp
  1.14% |1 |  1.08% | 5971 | huubatw...@gmail.com
  1.14% |1 |  1.07% | 5910 | rbar...@bbn.com
  1.14% |1 |  1.03% | 5661 | f...@cisco.com
  1.14% |1 |  1.02% | 5613 | n...@gnutls.org
  1.14% |1 |  1.02% | 5612 | m...@sap.com
  1.14% |1 |  1.00% | 5543 | l...@cisco.com
  1.14% |1 |  0.98% | 5420 | t...@huawei.com
  1.14% |1 |  0.98% | 5417 | joe...@bogus.com
  1.14% |1 |  0.96% | 5288 | d...@cridland.net
  1.14% |1 |  0.93% | 5117 | presn...@qualcomm.com
  1.14% |1 |  0.92% | 5072 | m...@let.de
  1.14% |1 |  0.92% | 5055 | m...@mnot.net
  1.14% |1 |  0.91% | 5040 | mstjo...@comcast.net
  1.14% |1 |  0.90% | 4949 | dwor...@avaya.com
  1.14% |1 |  0.89% | 4914 | t...@americafree.tv
  1.14% |1 |  0.87% | 4785 | bra...@isi.edu
  1.14% |1 |  0.86% | 4767 | d...@virtualized.org
  1.14% |1 |  0.84% | 4614 | ch...@ietf.org
  1.14% |1 |  0.83% | 4605 | b...@estacado.net
  1.14% |1 |  0.83% | 4564 | d...@xpasc.com
  1.14% |1 |  0.81% | 4485 | tglas...@earthlink.net
  1.14% |1 |  0.81% | 4459 | dw...@cisco.com
  1.14% |1 |  0.79% | 4343 | j...@bondis.org
  1.14% |1 |  0.78% | 4298 | d...@dotat.at
  1.14% |1 |  0.77% | 4239 | jo...@iecc.com
  1.14% |1 |  0.75% | 4127 | bacheb...@gmail.com
  1.14% |1 |  0.71% | 3902 | bmann...@sfc.keio.ac.jp
+--++--+
100.00% |   88 |100.00% |   552248 | Total
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My comments to the press about OAM for MPLS

[David Morris]

On Thu, 3 Mar 2011, Russ Housley wrote:

 
> It does not sound like the shutdown of the MEAD team was smooth.
> However, the closure of a design team when their output is being handled
> by a working group is quite normal.

>From following this thread, it sounds like the wrong IETF organization
unit was used to interface to the ITU?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My comments to the press about OAM for MPLS

[Brian E Carpenter]

On 2011-03-04 06:51, Russ Housley wrote:
> Nurit:
> 
>>> Not to mention including the canard that the IETF unilaterally disbanded
>>> "its group assigned to work with ITU" in 2009. Others with more detailed
>>> knowledge can explain exactly why this is, er, a lie.
>> Here are some facts:
>> ===
>> I was member of the MEAD team.
>> A meeting of the MEAD team was scheduled to meet in Munich
>> 12-14 October 2009. It was scheduled right after an ITU-T
>> SG15 plenary meeting (September 28 - October 9) because
>> MEAD team members attended that meeting too.
>>
>> On Friday October 2nd an agenda was distributed for the MEAD
>> team for the meeting in Munich on the MEAD team list m...@ietf.org.
>> On Monday October 5th an email was sent to m...@ietf.org
>> announcing the disbanding of the MEAD team, and that the
>> meeting in Munich should not be considered a MEAD team meeting.
>>
>> The decision to disband the MEAD team was liaised to the ITU-T
>> on the same day (October 5).
>>
>> Do I need to say more.
> 
> It does not sound like the shutdown of the MEAD team was smooth.  However, 
> the closure of a design team when their output is being handled by a working 
> group is quite normal.

That's the point. A design team is always a short term mechanism and once it
reports back to the WG, it closes down. Not having been personally
involved, I can't judge whether the process was clear to those involved,
especially people with more experience in ITU-T than in the IETF.

Just so we are all talking about the same thing, here is the official
description from BCP 25 (RFC 2418):

"6.5. Design teams

   It is often useful, and perhaps inevitable, for a sub-group of a
   working group to develop a proposal to solve a particular problem.
   Such a sub-group is called a design team.  In order for a design team
   to remain small and agile, it is acceptable to have closed membership
   and private meetings.  Design teams may range from an informal chat
   between people in a hallway to a formal set of expert volunteers that
   the WG chair or AD appoints to attack a controversial problem.  The
   output of a design team is always subject to approval, rejection or
   modification by the WG as a whole."

In other words, what counts in the IETF process is the WG consensus,
not the design team consensus. There are cases where the WG refuses or
significantly changes the design team proposal; RFC 3246 and RFC 3248
make a good example.

Brian


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

Re: My comments to the press about OAM for MPLS

[Russ Housley]

Nurit:

>> Not to mention including the canard that the IETF unilaterally disbanded
>> "its group assigned to work with ITU" in 2009. Others with more detailed
>> knowledge can explain exactly why this is, er, a lie.
> 
> Here are some facts:
> ===
> I was member of the MEAD team.
> A meeting of the MEAD team was scheduled to meet in Munich
> 12-14 October 2009. It was scheduled right after an ITU-T
> SG15 plenary meeting (September 28 - October 9) because
> MEAD team members attended that meeting too.
> 
> On Friday October 2nd an agenda was distributed for the MEAD
> team for the meeting in Munich on the MEAD team list m...@ietf.org.
> On Monday October 5th an email was sent to m...@ietf.org
> announcing the disbanding of the MEAD team, and that the
> meeting in Munich should not be considered a MEAD team meeting.
> 
> The decision to disband the MEAD team was liaised to the ITU-T
> on the same day (October 5).
> 
> Do I need to say more.

It does not sound like the shutdown of the MEAD team was smooth.  However, the 
closure of a design team when their output is being handled by a working group 
is quite normal.

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

Re: Last Call: (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax) to Informational RFC

[Rene Struik]

Dear colleagues:

Please find below my (modest) comments on draft-herzog-static-ecdh-05 (an 
update of the document that occurred since the moment 
of issuing the LC).

Best regards, Rene

==

I. Editorial comments:

(E-a) p. 1, Disclaimer, l. 3: "conclusions and" should read "conclusions, and".
(E-b) p. 11, Clause 7, l. -2: "Consder" should read "Consider".
(E-c) p. 12, Clause 7, last para before two bullet points, l. 3: "reciever" 
should read "receiver".
(E-d) p. 13, Clause 10.2, l. -3: The paper by Menezes and Ustaoglu has appeared 
in International Journal of Applied Cryptography, 
Vol. 2, No. 2, pp. 154-158, 2010.
(E-e) p. 4, l. -5: The motivation for specifying ECDH seems to be not so much 
that ECMQV is around (but having problems, as you stated), 
but that static-static-ECDH is *not* around. Thus, specifying 
static-static-ECDH adds more options to the solution space.

II. Technical comments:

(T-f) p. 5, Clause 1, forelast bullet: The term "data integrity" is more aptly 
called "data authenticity" (and would also align well with 
AuthenticatedData CMS structure called out at the beginning of the same 
sentence). NOTE - I am aware of the "attack in Clause 7, but this 
attack seems to be more a flaw in the original CMS scheme, since effective 
irrespective of the key agreement method (i.e., not just static-
static-ECDH): A --> B: E_K(k) || Secured_k(m) allows any entity C who obtains 
the same key k to replace Secured_k(m) by another valid 
string. This suggests that (1) one should call this out in the text; (2) one 
should fix the original problem with CMS (e.g., tieing k to K, the
originator, or recipient via, e.g., a one-way function.

(T-g) p. 6, Clause 2.2, l. -5: At first, it is suggested that the sending agent 
obtains the recipient's public key somehow (e.g., from its 
certificate), thus suggesting that certificates are not the only option by 
which the public key may be obtained. However, later on it is stated 
that "it confirms that both certificates [...]", thus suggesting that each of 
the parties involved in this message flow have public keys that
are certified and that only those can be used. This is confusing.

(T-h) p. 6, Clause 2.2, l. -6 ff: Given the lack of shall/should/may language, 
it is unclear whether one stipulates that one
checks that public keys in the certificate are on a specific curve (i.e., one 
does public key validation) or something more relaxed (such as checking
that the claimed elliptic curve domain parameters are the same, without 
checking the public keys themselves. The para would benefit from some 
firmed-up language here. This should also clarify whether one, in fact, checks 
the validity of the certificate that included the public key.

(T-i) p. 7, Clause 2.3, l. 8 ff: same comment as T-h, but now for recipient's 
side.

(T-j) p. 11, Clause 6, l. 4 (also l. 16): I was hoping that by now (2011), the 
unkeyed hash function SHA-1 would be moth-balled (rather than 
reintroducing this option), more than 5 years after more serious SHA-1 attacks 
were presented in the academic community.
 
(T-k) p. 11, Clause 6, l. 3 (also l. 15): Why not introduce the CTR encryption 
mode as an option, at least when authenticity is provided? 
After all, CTR mode allows implementation of block-ciphers with just the 
forward encryption mode and offers parallelization and precomputation 
prospects.

(T-l) General: When static-static ECDH, as specified here, stipulates checking 
of the certificate including the public key and that certificate is
an ECDSA certificate, significant speed-ups of the computations are possible by 
combining the key computation step and ECDSA signature verification
-- cf. http://www.ietf.org/proceedings/78/slides/saag-7.pdf. 
 or the SAC 2010 paper 
referenced in that IETF-78 presentation. These results also apply here
(and can obviously be ignored or embraced depending upon implementation). I 
would suggest adding a one-line statement that if ECDSA is used, one shall 
use the "friendly ECDSA" scheme as in the IETF-78 presentation (which has the 
same format as the ordinary one).

Rene


On 02/02/2011 4:55 PM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in
>Cryptographic Message Syntax'
>as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-03-02. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/
>
> IESG discussion can be 

Fwd: [apps-discuss] timezone database maintenance

[Peter Saint-Andre]

FYI. Please direct follow-ups to the apps-discuss list:

https://www.ietf.org/mailman/listinfo/apps-discuss

 Original Message 
Subject: [apps-discuss] timezone database maintenance
Date: Thu, 03 Mar 2011 09:45:35 -0700
From: Peter Saint-Andre 
To: apps-disc...@ietf.org 

Dear Apps Folks,

We need to finish our work on draft-lear-iana-timezone-database and
decide if we will pursue the approach outlined in that document, so that
Mr. David Olson (maintainer of the timezone database) can work for a
while within the new processes before starting his well-deserved retirement.

I plan to issue an IETF Last Call on that I-D soon after IETF 80. To
expedite the conversation, I encourage those who care about future
management of the timezone database to weigh in on the apps-discuss
list. In addition, I have reserved a room from 08:00 to 09:00 on
Wednesday, March 30 at the IETF meeting in Prague, so please add that
time slot to your calendar if you wish to participate.

Thanks!

Peter

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



___
apps-discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Andrew Sullivan]

On Thu, Mar 03, 2011 at 04:57:39PM +0200, Mykyta Yevstifeyev wrote:

> Andrew, in this case how do you propose to formulate this?  Mykyta

"Not"?  The goal you appear to have in this is to make the RFC series
tidy.  As the co-chair of a WG with an old and decidedly messy set of
protocol documents, I understand and value that desire.  But as the
same co-chair, I have to tell you that any assertion that some feature
(even if you think it is a dumb one that nobody ever should have used
anywhere for any reason) is unused is the sort of thing that leads you
into discussions of angels and pin-heads, trees falling in forests
with no-one to hear, and so no.

Heck, over in DNS land, we are barely willing to rely on features of
the protocol if we know that there is a 10 year old but once
widely-deployed piece of software that violated or didn't implement
that feature.

Setting up criteria that are formally nice but for which it is
impossible to construct a test is a bad idea.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[John C Klensin]

--On Thursday, March 03, 2011 10:41 -0500 "Joel M. Halpern"
 wrote:

> No, I do not agree with you.
> Our current definition for historic, and our current choices
> for when to move things, have worked sufficiently well.
> I have not seen any evidence that there is a problem that
> needs solving.
> I have also not seen any evidence that the changes you propose
> to the definitions would help anything.
> 
> Yes, there are problems with our current definitions.
> Those problems serve to keep us from declaring something
> historic when we shouldn't.
>...

I pretty much agree with Joel (and others), but suggest that
there is another, better, solution to this problem (or at least
the version of it I understand).

Ultimately, whether under 2026 or your proposal, there are
ultimately two reasons for making something historic (this is
different from your Section 2 list; more about that below):

(i) No one is using the protocol and no one cares any
more about it. 

(ii) The protocol contains elements or defects that, in
retrospect, make it dangerous.

With the exceptions that are already covered by the existing
"Obsoleted by" category, the first is, as Joel points out, hard
to identify and get agreement about.   As other have suggested,
"no one cares" means "no one cares", i.e., that putting
significant energy into trying to identify and classify those
documents is probably not a good use of community resources.
Reaching formal agreement about the second effectively requires
publication of an RFC that describes the problem, at which point
"Obsoletes" can be used and there is no reason to develop new
procedures.

For the few cases that are actually worth it, we do have the
ability to approve and publish documents that identify a
protocol as "not recommended".  We don't use stand-alone
Applicability Statements very often any more, especially for
that purpose, but, if a particular protocol deserved the effort,
it would be lots easier --and lots less wear and tear on the
community in review and the RFC Editor in publication-- to write
an I-D that said "the protocol described in RFC  has turned
out to be a bad idea because... Its use is Not Recommended."
than to republish or "historicize" as you suggest.

Trying to turn Historic even more into an ambiguous synonym for
"old", "unused", "uninteresting", or "bad" just does not strike
me as a good idea, especially with the possibility of
applicability statements that are orthogonal to maturity level
classification on the books.

FWIW, your "republication as historic" approach is not feasible
for documents more than a few years old.  The rules about
information to be included in RFCs, how that information is
structured, IPR statements, etc., have evolved over the years.
Permitting republication of an old RFC in facsimile would often
break those rules.  Figuring out the mechanisms for getting
around that would cost far more in resources than the community
is, I believe, willing to invest.  If I thought that another
iteration would improve this proposal enough to make it
acceptable, I'd recommend that your Section 3.1 should be
required to address republication of new documents with
identical technical content with old ones in the light of those
rules.   But I don't think that is the case.

On a note of sadness rather than as a sales pitch, the community
has discussed several ways of dealing with what I think it the
underlying problem you are trying to address -- getting readers
of RFCs the most up to date information possible about those
documents and the status of the protocols they describe.   At
least some of them would have worked better than this, with less
load on the community.  For whatever reasons, none of them have
achieved sufficient consensus to move forward.  Against that
background, I can't imagine what would cause us to adopt a
weaker proposal that required more work.

regards,
john

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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[RJ Atkinson]

Earlier, Joel Halpern wrote:
> The first point, to echo Andrew Sullivan, is that even if a protocol
> is in use on the public Internet, it is not always easy to detect.
> It may be used in only some portions of the net.  It may be used
> inside some other protocol that makes detection ahrder. 
> 
> The second point is that enterprise uses and other private network uses 
> are still valid uses. The fact that a protocol may be used only inside 
> a virtual private network, or only inside a corporate data center,
> or in only within a military facility, does NOT mean that it is not used. 
> Such limited use is still valid use and should not result in our 
> declaring something obsolete.

+1 to all of the above.  


As an example of the 2nd point above, earlier this decade the IESG 
erroneously reclassified RFC-1108 as Historic, apparently because they 
perceived it as "not in use", even though it probably has more deployment 
and broader implementation now than 10 or 15 years ago.  
Here are 3 examples of modern products that support it:
- Cisco IOS still supports RFC-1108, and has since the early 1990s.
  

- Oracle (Sun) Solaris supports it, although they call it "RIPSO".
  

- Trusted Linux/SE Linux also supports it.
  


A third issue is that one of the apparent objectives is to reclassify 
a large number of RFCs that pre-date the IETF, and/or that were NOT 
published as IETF track RFCs.  What we now call the "Individual 
Submission" track is the oldest track of all, since the IETF 
did not even exist until the middle 1980s, yet RFCs go back to 1969.


Fourth, it is not appropriate for the IETF (or IESG) to reclassify any 
RFC that was not originally published as an IETF track RFC.  The IETF
simply lacks authority to reclassify such RFCs, although if the 
original author explicitly consents in advance to the reclassification
(e.g. recently for MD2/MD4) this can be done.  This is particularly 
true for the older RFCs that appear to be the target of this I-D and 
I-D author.  For those older RFCs, it isn't even the case the the 
IETF Trust (or ISoc) hold any well defined rights.


So the document also needs to clearly say that only IETF track RFCs
are within the scope of this document, and that the document does
not apply to RFCs which pre-date the IETF existence or that were
not published as IETF-track RFCs.

Yours,

Ran



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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Joel M. Halpern]

No, I do not agree with you.
Our current definition for historic, and our current choices for when to 
move things, have worked sufficiently well.

I have not seen any evidence that there is a problem that needs solving.
I have also not seen any evidence that the changes you propose to the 
definitions would help anything.


Yes, there are problems with our current definitions.
Those problems serve to keep us from declaring something historic when 
we shouldn't.
They do, as a side effect, make it harder to declare things historic 
even if they actually are?
I will even agree that there is a small cost to that.  Users of our 
standards may sometimes think some things are relevant that aren't.


But changing the definitions to make it easier to change the status does 
not actually change the problem.  The problem is that it is hard for 
anyone (the IETF, vendors, operators) to reliably know what is actually 
in use.


Yours,
Joel

PS: I have actually noticed with several specifications I worked with 
that it can easily take 5 or 10 years for the actual usage (often not 
the initially expected usage) for a standards track or experimental 
protocol to emerge.  So premature declaration taht something is historic 
can do actual damage.


On 3/3/2011 10:28 AM, Mykyta Yevstifeyev wrote:

Joel,

I agree with you that it is really hard and even impossible to determine
what is going on in the Internet regarding some technology, protocol,
etc. If we set the impossible criterion for the Historic documents, this
will really make very few sense. So, as I have been pointed out, I find
removing the regulation about 'out-of-use' technology at all quite
acceptable. Do you agree?

And as for the comment from Dave.

03.03.2011 17:18, Dave CROCKER wrote:



On 3/3/2011 7:11 AM, Joel M. Halpern wrote:

The first point, to echo Andrew Sullivan, is that even if a protocol
is in use
on the public Internet, it is not always easy to detect.

...

The second point is that enterprise uses and other private network
uses are
still valid uses. The fact that a protocol may be used only inside a
virtual
private network, or only inside a corporate data center, or in only
within a
military facility, does NOT mean that it is not used. Such limited
use is still
valid use and should not result in our declaring something obsolete.



+1

Declaration of historic needs to be based on affirmative data. The
declaration is actually only important to make for protocols that are
known to be problematic.

This is already covered by the 'deprecated' criteria in my draft.

All the best,
Mykyta Yevstifeyev


Issuing a declaration for mere non-use is a matter of convenience, not
need, IMO.

d/


03.03.2011 17:11, Joel M. Halpern wrote:

There are, in my opinion, two problems with Mr. Yevstifeyev's
assertion below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol
is in use on the public Internet, it is not always easy to detect. It
may be used in only some portions of the net. It may be used inside
some other protocol that makies detection ahrder.
The second point is that enterprise uses and other private network
uses are still valid uses. The fact that a protocol may be used only
inside a virtual private network, or only inside a corporate data
center, or in only within a military facility, does NOT mean that it
is not used. Such limited use is still valid use and should not result
in our declaring something obsolete.

Yours,
Joel

On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote:

Hello Eliot,

Thank you for reading the document. Pleas efind some comments in-line.

2011/3/2, Eliot Lear:

...

I bring to your attention RFC-4450, in which we made a bulk status
change of a bunch of PS to Historic precisely because we couldn't find
anyone using those protocols. However, such observations are
imprecise. For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ). Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.


When we say 'out-of-use' we consider the usage of something in the
overall Internet. It is mostly not very difficault to find this out
via those people who take part in the IETF.

...





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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Mykyta Yevstifeyev]

Joel,

I agree with you that it is really hard and even impossible to determine 
what is going on in the Internet regarding some technology, protocol, 
etc.   If we set the impossible criterion for the Historic documents, 
this will really make very few sense.  So, as I have been pointed out, I 
find removing the regulation about 'out-of-use' technology at all quite 
acceptable.  Do you agree?


And as for the comment from Dave.

03.03.2011 17:18, Dave CROCKER wrote:



On 3/3/2011 7:11 AM, Joel M. Halpern wrote:
The first point, to echo Andrew Sullivan, is that even if a protocol 
is in use

on the public Internet, it is not always easy to detect.

...
The second point is that enterprise uses and other private network 
uses are
still valid uses. The fact that a protocol may be used only inside a 
virtual
private network, or only inside a corporate data center, or in only 
within a
military facility, does NOT mean that it is not used. Such limited 
use is still

valid use and should not result in our declaring something obsolete.



+1

Declaration of historic needs to be based on affirmative data.  The 
declaration is actually only important to make for protocols that are 
known to be problematic.

This is already covered by the 'deprecated' criteria in my draft.

All the best,
Mykyta Yevstifeyev


Issuing a declaration for mere non-use is a matter of convenience, not 
need, IMO.


d/


03.03.2011 17:11, Joel M. Halpern wrote:
There are, in my opinion, two problems with Mr. Yevstifeyev's 
assertion below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol 
is in use on the public Internet, it is not always easy to detect.  It 
may be used in only some portions of the net.  It may be used inside 
some other protocol that makies detection ahrder.
The second point is that enterprise uses and other private network 
uses are still valid uses.  The fact that a protocol may be used only 
inside a virtual private network, or only inside a corporate data 
center, or in only within a military facility, does NOT mean that it 
is not used. Such limited use is still valid use and should not result 
in our declaring something obsolete.


Yours,
Joel

On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote:

Hello Eliot,

Thank you for reading the document.  Pleas efind some comments in-line.

2011/3/2, Eliot Lear:

...

I bring to your attention RFC-4450, in which we made a bulk status
change of a bunch of PS to Historic precisely because we couldn't find
anyone using those protocols.  However, such observations are
imprecise.  For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ).  Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.


When we say 'out-of-use' we consider the usage of something in the
overall Internet.  It is mostly not very difficault to find this out
via those people who take part in the IETF.

...



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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Peter Saint-Andre]

On 3/3/11 8:18 AM, Dave CROCKER wrote:
> 
> 
> On 3/3/2011 7:11 AM, Joel M. Halpern wrote:
>> The first point, to echo Andrew Sullivan, is that even if a protocol
>> is in use
>> on the public Internet, it is not always easy to detect.
> ...
>> The second point is that enterprise uses and other private network
>> uses are
>> still valid uses. The fact that a protocol may be used only inside a
>> virtual
>> private network, or only inside a corporate data center, or in only
>> within a
>> military facility, does NOT mean that it is not used. Such limited use
>> is still
>> valid use and should not result in our declaring something obsolete.
> 
> 
> +1
> 
> Declaration of historic needs to be based on affirmative data.  The
> declaration is actually only important to make for protocols that are
> known to be problematic.
> 
> Issuing a declaration for mere non-use is a matter of convenience, not
> need, IMO.

And, further, probably it would not be worth the trouble to investigate
whether a protocol is not actually used (proving a negative is hard).

Peter

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





smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Dave CROCKER]

On 3/3/2011 7:11 AM, Joel M. Halpern wrote:

The first point, to echo Andrew Sullivan, is that even if a protocol is in use
on the public Internet, it is not always easy to detect.

...

The second point is that enterprise uses and other private network uses are
still valid uses. The fact that a protocol may be used only inside a virtual
private network, or only inside a corporate data center, or in only within a
military facility, does NOT mean that it is not used. Such limited use is still
valid use and should not result in our declaring something obsolete.



+1

Declaration of historic needs to be based on affirmative data.  The declaration 
is actually only important to make for protocols that are known to be problematic.


Issuing a declaration for mere non-use is a matter of convenience, not need, 
IMO.

d/
--

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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Joel M. Halpern]

There are, in my opinion, two problems with Mr. Yevstifeyev's assertion 
below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol is 
in use on the public Internet, it is not always easy to detect.  It may 
be used in only some portions of the net.  It may be used inside some 
other protocol that makies detection ahrder.
The second point is that enterprise uses and other private network uses 
are still valid uses.  The fact that a protocol may be used only inside 
a virtual private network, or only inside a corporate data center, or in 
only within a military facility, does NOT mean that it is not used. 
Such limited use is still valid use and should not result in our 
declaring something obsolete.


Yours,
Joel

On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote:

Hello Eliot,

Thank you for reading the document.  Pleas efind some comments in-line.

2011/3/2, Eliot Lear:

...

I bring to your attention RFC-4450, in which we made a bulk status
change of a bunch of PS to Historic precisely because we couldn't find
anyone using those protocols.  However, such observations are
imprecise.  For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ).  Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.


When we say 'out-of-use' we consider the usage of something in the
overall Internet.  It is mostly not very difficault to find this out
via those people who take part in the IETF.

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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Mykyta Yevstifeyev]

03.03.2011 13:56, Andrew Sullivan wrote:

On Thu, Mar 03, 2011 at 11:27:21AM +0200, Mykyta Yevstifeyev wrote:

2011/3/2, Eliot Lear:

imprecise.  For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ).  Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.


When we say 'out-of-use' we consider the usage of something in the
overall Internet.  It is mostly not very difficault to find this out
via those people who take part in the IETF.

If I read the above exchange correctly, Eliot Lear points out that it
is difficult to observe what's going on all over the Internet, on the
premise that the Internet is a bunch of interconnected networks and
you can't be sure that you've actually observed all of those networks
(some of which might be closed to you).

In response, Mykyta Yevstifeyev says, "Oh, that's not hard.  People at
the IETF know."  This has no supporting argument for it at all.

I would like to suggest that the former position is the better one to
take.

Andrew, in this case how do you propose to formulate this?  Mykyta

A



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

RE: My comments to the press about OAM for MPLS

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

Huub,
Good that you mention that you were part of the design team! That is correct.
You were also part of the team that worked in the face-to-face MEAD team 
meeting in Stockholm, July 2009, on the design and the technical direction for 
OAM in MPLS-TP. You were part of the team that presented the outcome of the 
MEAD team meeting and their recommendations to the MPLS WG in Stockholm. The 
IETF has started working on the solution based on these recommendations! 
See the authors in 
http://www.ietf.org/proceedings/75/slides/mpls-17/mpls-17_files/frame.htm.  
Nurit

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext 
Huub van Helvoort
Sent: Thursday, March 03, 2011 11:38 AM
To: Brian E Carpenter
Cc: IETF
Subject: Re: My comments to the press about OAM for MPLS

Hello Brian,

You wrote:

> Not to mention including the canard that the IETF unilaterally disbanded
> "its group assigned to work with ITU" in 2009. Others with more detailed
> knowledge can explain exactly why this is, er, a lie.

Here are some facts:
===
I was member of the MEAD team.
A meeting of the MEAD team was scheduled to meet in Munich
12-14 October 2009. It was scheduled right after an ITU-T
SG15 plenary meeting (September 28 - October 9) because
MEAD team members attended that meeting too.

On Friday October 2nd an agenda was distributed for the MEAD
team for the meeting in Munich on the MEAD team list m...@ietf.org.
On Monday October 5th an email was sent to m...@ietf.org
announcing the disbanding of the MEAD team, and that the
meeting in Munich should not be considered a MEAD team meeting.

The decision to disband the MEAD team was liaised to the ITU-T
on the same day (October 5).


Do I need to say more.

Regards, Huub.



-- 
*
  我爱外点一七三一
___
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: Request for review of draft-yevstifeyev-genarea-historic-03

[Andrew Sullivan]

On Thu, Mar 03, 2011 at 11:27:21AM +0200, Mykyta Yevstifeyev wrote:
> 2011/3/2, Eliot Lear :

> > imprecise.  For one, it is hard to observe what is going on on the
> > Internet, and those who do don't usually share their data (there is
> > some, but it is often regionally based, like the GINORMOUS store at
> > ETHZ).  Another issue is that a protocol that is not detectable on the
> > Internet might be in use on private networks.
> >
> When we say 'out-of-use' we consider the usage of something in the
> overall Internet.  It is mostly not very difficault to find this out
> via those people who take part in the IETF.

If I read the above exchange correctly, Eliot Lear points out that it
is difficult to observe what's going on all over the Internet, on the
premise that the Internet is a bunch of interconnected networks and
you can't be sure that you've actually observed all of those networks
(some of which might be closed to you).

In response, Mykyta Yevstifeyev says, "Oh, that's not hard.  People at
the IETF know."  This has no supporting argument for it at all.

I would like to suggest that the former position is the better one to
take.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My comments to the press about OAM for MPLS

[Huub van Helvoort]

Hello Brian,

You wrote:


Not to mention including the canard that the IETF unilaterally disbanded
"its group assigned to work with ITU" in 2009. Others with more detailed
knowledge can explain exactly why this is, er, a lie.


Here are some facts:
===
I was member of the MEAD team.
A meeting of the MEAD team was scheduled to meet in Munich
12-14 October 2009. It was scheduled right after an ITU-T
SG15 plenary meeting (September 28 - October 9) because
MEAD team members attended that meeting too.

On Friday October 2nd an agenda was distributed for the MEAD
team for the meeting in Munich on the MEAD team list m...@ietf.org.
On Monday October 5th an email was sent to m...@ietf.org
announcing the disbanding of the MEAD team, and that the
meeting in Munich should not be considered a MEAD team meeting.

The decision to disband the MEAD team was liaised to the ITU-T
on the same day (October 5).


Do I need to say more.

Regards, Huub.



--
*
 我爱外点一七三一
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Mykyta Yevstifeyev]

Hello Eliot,

Thank you for reading the document.  Pleas efind some comments in-line.

2011/3/2, Eliot Lear :
> Thank you for the opportunity to review this draft.  I do so merely as
> an individual.  It might be a good idea to provide some additional
> clarity on when to market something Historic, but your document requires
> a bit of clarity on its own as to what your motivating logic is.  Why,
> for instance, do you believe it is important to split "deprecated" and
> "obsoleted"?
>
In my opinion, the term 'obsoleted' means that it is out-of-use while
'deprected' means that it not recommended to be used and implemented
because of some reason.
>
> Also, Scott had to choose some language to describe
> Historic.  He probably did not mean for us to get hung up on the word
> "superceded", a problem from which this draft seems to suffer.
>
RFC 2026 says that Historic is for RFCs that has been superseded by a
more recent specification or is for any other reason considered to be
obsolete.  However some recent observations have shown that everyone
has their own thoughts on what the word 'obsolete' means.  Some think
that it is the synonym yo the word 'superseded' while other consider
it to be 'deprectaed' as well.  I propose to provide the clarity on
this terms.
>
> I bring to your attention RFC-4450, in which we made a bulk status
> change of a bunch of PS to Historic precisely because we couldn't find
> anyone using those protocols.  However, such observations are
> imprecise.  For one, it is hard to observe what is going on on the
> Internet, and those who do don't usually share their data (there is
> some, but it is often regionally based, like the GINORMOUS store at
> ETHZ).  Another issue is that a protocol that is not detectable on the
> Internet might be in use on private networks.
>
When we say 'out-of-use' we consider the usage of something in the
overall Internet.  It is mostly not very difficault to find this out
via those people who take part in the IETF.

You've also given me the idea to mention the criterion for 'obsoleted'
documents such as it is the retired or revised Internet standard, per
RFC 2026.  I'll make this change in my working copy of the draft.

All the best,
Mykyta Yevstifeyev
>
> Eliot
>
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf