Re: "Deprecate"

2013-09-05 Thread t . p .
it would mean we are approving 4020bis without knowing what it > means, until 5226bis is approved. Actually, it would be pointless as things stand since all that 5226bis has in it is "I was looking through the 5226bis draft and there is nothing in there about how to deprecate values

RE: "Deprecate"

2013-08-29 Thread Dearlove, Christopher (UK)
arnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -Original Message- From: Michelle Cotton [mailto:michelle.cot...@icann.org] Sent: 29 August 2013 15:53 To: Dearlove, Christopher (UK); t.p.; ietf Subject: Re: "Deprecate" We are working on 5226bis ri

Re: "Deprecate"

2013-08-29 Thread t . p .
Original Message - From: "Adrian Farrel" To: "'Michelle Cotton'" ; "'Dearlove, Christopher (UK)'" ; "'t.p.'" ; "'ietf'" Sent: Thursday, August 29, 2013 4:13 PM Subject: RE: "Deprecate"

RE: "Deprecate"

2013-08-29 Thread Adrian Farrel
ietf > Subject: Re: "Deprecate" > > We are working on 5226bis right now and have a plans to discuss the term > in there. > > --Michelle Cotton > > Michelle Cotton > Manager, IANA Services > ICANN > > > > On 8/29/13 5:22 AM, "Dearlove,

Re: "Deprecate"

2013-08-29 Thread Michelle Cotton
45 242124 >chris.dearl...@baesystems.com | http://www.baesystems.com > >BAE Systems (Operations) Limited >Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >Centre, Farnborough, Hants, GU14 6YU, UK >Registered in England & Wales No: 1996687 >

RE: "Deprecate"

2013-08-29 Thread Dearlove, Christopher (UK)
tf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.p. Sent: 29 August 2013 12:56 To: ietf Subject: "Deprecate" --! WARNING ! -- This message originates from outside our organisation, either from an external partner or from the internet. Keep thi

RE: "Deprecate"

2013-08-29 Thread Adrian Farrel
tf > Subject: "Deprecate" > > I recently saw 'deprecate' used in an IANA Considerations and turned to > "IANA Considerations" [RFC5226] to see how it was defined only to find > no mention of it there. I am used to the term from SMI, as quoted > below, but

"Deprecate"

2013-08-29 Thread t . p .
I recently saw 'deprecate' used in an IANA Considerations and turned to "IANA Considerations" [RFC5226] to see how it was defined only to find no mention of it there. I am used to the term from SMI, as quoted below, but that seems not quite right, in that a deprecated IANA en

Re: [Ietf-krb-wg] Last Call: (Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos) to Best Current Practice

2012-03-24 Thread Sam Hartman
Hi. In the writeup I asked Stephen to include a note that there is a normative downreference to RFC 4757. RFC 4757 is informational. This document recommends that implementations not implement some of the algorithms in RFC 4757, thus creating a normative down-ref. My opinion and that of the WG is

Re: Last Call: (Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos) to Best Current Practice

2012-03-22 Thread Joel jaeggli
On 3/22/12 08:26 , The IESG wrote: > > The IESG has received a request from the Kerberos WG (krb-wg) to consider > the following document: > - 'Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms >in Kerberos' >as a Best Current Practice &

Re: secid review of draft-ietf-ipv6-deprecate-rh0-01

2007-10-02 Thread Joe Abley
On 1-Oct-2007, at 0511, Jari Arkko wrote: Hi David, and thanks for your review. Inline: As such, the whole document is a security consideration. The vulnerability appears well-documented, and the guidelines for handling the deprecated RH0 are clear. Good. Just by-the-by, I noticed the

Re: secid review of draft-ietf-ipv6-deprecate-rh0-01

2007-10-01 Thread Jari Arkko
Hi David, and thanks for your review. Inline: > As such, the whole document is a security consideration. The > vulnerability appears well-documented, and the guidelines for handling > the deprecated RH0 are clear. > Good. > I have a few comments > 1) RH0 really is something we do not want to

Re: secid review of draft-ietf-ipv6-deprecate-rh0-01

2007-09-25 Thread Sam Hartman
So, BCP 61's claim that MUST is for implementers and SHOULD is for users is always something I've interpreted as non-normative and additional explanation of RFC 2199. Well, I' guess it is normative in that we do not for security reasons require that security be used. I certainly think reviewing

secid review of draft-ietf-ipv6-deprecate-rh0-01

2007-09-24 Thread David Harrington
just like any other last call comments. - The purpose of draft-ietf-ipv6-deprecate-rh0-01 is to deprecate a feature of IPv6 which has been shown to have undesirable security implications. In particular, RH0 provides a mechanism for traffic amplification, which might be used as a denial-of-se

Gen-art review of draft-ietf-ipv6-deprecate-rh0-01

2007-09-21 Thread Elwyn Davies
-ipv6-deprecate-rh0-01.txt Reviewer: Elwyn Davies Review Date: 21/9/07 IETF LC End Date: 20/9/07 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. I have a couple of essentially editorial comments below. Comments: s3: "IPv6 nodes **MUST NOT process** R

Re: Last Call: draft-ietf-ipv6-deprecate-rh0 (Deprecation of Type 0 Routing Headers in IPv6) to Proposed Standard

2007-09-11 Thread Jari Arkko
I wanted to mention a few points regarding this document, given that the matter has been the subject of some controversy. There was clear consensus in the WG for picking this approach, but it was also a rough consensus, with a number of differing opinions. One of the concerns was that the discusse