Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Feb 2011 15:56:05 -0500

Whoops, tomorrow would be a month since I last poked this, so shame on  
me...

Could I get others to chime in here with comments? Should I ask for  
this to be considered for WGLC[0]?

W

[0]: Yes, I *am* poking the stick in the nest and giving it a shake to  
see if anything flies out and bites me. :-)

On Jan 17, 2011, at 8:55 AM, t.petch wrote:

> Looks good to me.
>
> I thought briefly that the language ought to be SHOULD or MUST but  
> then
> realised that this I-D is INFORMATIONAL so that those would not
> really be appropriate.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Warren Kumari" <[email-masked]>
> To: "t.petch" <[email-masked]>
> Cc: "Warren Kumari" <[email-masked]>; "idr" <[email-masked]>
> Sent: Sunday, January 16, 2011 4:28 PM
> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00
>
>
>
> On Dec 30, 2010, at 12:37 PM, t.petch wrote:
>
>> Warren
>>
>> Top posting on deprecate since that seems the fuzzy issue.
>>
>> I also work in network management, and so take for granted  
>> statements such as
>> " The value "current" means that the definition is current and valid.
>>  The value "obsolete" means the definition is obsolete and should not
>>  be implemented and/or can be removed if previously implemented.
>>  While the value "deprecated" also indicates an obsolete definition,
>>  it permits new/continued implementation in order to foster
>>  interoperability with older/existing implementations."
>>
>> from SMIv2 [RFC2578] and which is almost unchanged in YANG [RFC6020]
>>
>> "The "status" statement takes as an argument one of the strings
>>  "current", "deprecated", or "obsolete".
>>
>>  o  "current" means that the definition is current and valid.
>>
>>  o  "deprecated" indicates an obsolete definition, but it permits  
>> new/
>>     continued implementation in order to foster interoperability with
>>     older/existing implementations.
>>
>>  o  "obsolete" means the definition is obsolete and SHOULD NOT be
>>     implemented and/or can be removed from implementations."
>>
>> I have always taken this to be IETF-wide so that when RFC4271 uses
>> 'deprecated' without explanation, everyone knows what is meant.  As
>> such, I would suggest not including any definition thereof. If it  
>> is good
> enough
>> for RFC4271, .....
>
> Cool, done!
>
>>
>> But I would still include explicit sentences along the lines of 'do  
>> not
> generate
>> any new ones, and stop using existing ones as soon as you can'
>
> Version -01 included some strengthened text, but I've just posted -02.
> Please have a look and let me know if you think this is the correct  
> strength --
> it's basically what you provided, but reworded slightly to be a  
> little more
> "formal".
>
> W
>
>>
>> Tom Petch
>>
>> ps you could include a reference to maidens praying, but that is  
>> probably
>> too much an SNMP in-joke.
>>
>> ----- Original Message -----
>> From: "Warren Kumari" <[email-masked]>
>> To: "t.petch" <[email-masked]>
>> Cc: "Warren Kumari" <[email-masked]>; <[email-masked]>
>> Sent: Wednesday, December 29, 2010 11:08 PM
>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00
>>
>> On Dec 8, 2010, at 4:16 AM, t.petch wrote:
>>
>>> ----- Original Message -----
>>> From: "Warren Kumari" <[email-masked]>
>>> To: "Warren Kumari" <[email-masked]>
>>> Cc: <[email-masked]>
>>> Sent: Tuesday, December 07, 2010 6:10 PM
>>> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00
>>>
>>>
>>>> From the lack of slings and arrows, I'm going to have to assume  
>>>> that this
>>> document is just *perfect* and cannot be improved at all....
>>>>
>>>> Go, prove me wrong (please?)
>>>
>>> Easy peasy
>>
>> Doh. I said that I'd get to soon, but, well, I didn't.... Sorry.
>>>
>>> "The reductions  ...  is outweighed "
>>
>> Good catch. Done.
>>>
>>> "Deprecate:  To mark ...  as obsolete"
>>> **disagree obsolete and deprecate are quite different and I think  
>>> deprecate
>>> correct here (but see below).
>>>
>>
>> Yes, I agree. This is horrid, but I wasn't able to find a better  
>> definition of
>> "deprecate" anywhere...
>> I have spent a while looking at various definitions and have munged  
>> a few of
>> them together into one :-)
>> Hopefully this is a reasonable, otherwise, if you happen to be able  
>> to
> wordsmith
>> a better one I'd really appreciate it.
>>
>>
>>> "RPKI"
>>> ** not expanded, explained or referenced, nor mentioned in the  
>>> introduction.
>>
>> Bah! I didn't want to have the document held up while waiting for
>> draft-ietf-sidr-arch-11 (or similar) to be published, so I tossed  
>> in "RPKI",
>> intending to find a good reference before posting it, but then  
>> forgot...
>>
>> I have reworded things to avoid using the term RPKI, hopefully this  
>> is still
>> specific enough.
>>
>>> For me, RPKI is the driving force for this I-D - I know of no  
>>> other reason
> for
>>> it to exist so more is needed here.
>>
>> While RPKI is the reason closest to my heart as well, it is not the  
>> only
>> reason -- AS_SETs have caused both confusion and issues, for example:
>> http://www.merit.edu/mail.archives/nanog/msg14479.html
>>
>> This is (IMO) both because the code is not well exercised and  
>> because the
>> relevant bits of the RFC are, um, confusing. AS_SETs also seem to  
>> cause
>> confusion to many operators -- if I see:
>> *> 192.0.2.0/24     1  12  22  9  6 i
>> I know exactly who to talk to about issues with 192.0.2.0. If I see:
>> *> 192.0.2.0/24     1 12 {22 9 6} i
>> who should I talk to? AS12? AS6? All of them, none of them?
>>
>> And what exactly does AS_PATH 3561 3356 9031  
>> {35821,35821,35821,35821} i mean?
>> (http://www.gossamer-threads.com/lists/cisco/nsp/137647?do=post_view_threaded_
>>
>>>
>>> "simplified..  "
>>
>> Done.
>>
>>>
>>> Is there an exposure from systems that will refuse to process AS- 
>>> SET when
>>> receiving one, eg a black hole?  I don't know, but think it needs  
>>> exploring.
>>
>>
>> If someone is announcing an aggregate containing an AS_SET, and is  
>> not
>> announcing the more specifics as well, then yes, this could happen  
>> -- I have
> not
>> been able to find any cases of this though. I guess it is also  
>> possible that a
>> more specific could go away, and the aggregator may have some  
>> backdoor route
> to
>> a contributor, but a: this is getting into the pathological and b:  
>> we are
>> advising folk to stop generating these anyway :-P
>>
>>
>>>
>>> And, just what is being recommended?  Deprecate is a weasel word  
>>> and I think
>>> needs elucidating ie spell out whatever it is we are  
>>> recommending.  I take it
>> as
>>> do not generate any new AS_SET and look to eliminate any that are  
>>> currently
>>> being generated, but think that that needs saying explicitly.
>>
>> Yup, that is it exactly. I have attempted to demustelate it -- I  
>> would like to
>> make it even stronger[0], but think that this is now explicit  
>> enough, you?
>>
>> W
>>
>> [0]: Like "Warning: AS_SETs and AS_CONFED_SETs are going away.  
>> Please stop
>> announcing them or some chappie with a big bat will come knocking..."
>>
>>> Tom Petch
>

---

From: "t.petch" <[email-masked]>
Date: Fri, 18 Feb 2011 11:18:44 +0100

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "idr" <[email-masked]>
Sent: Wednesday, February 16, 2011 9:56 PM
Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

> Whoops, tomorrow would be a month since I last poked this, so shame on

Yes but who are you poking?  I am happy with and would welcome
a WG LC, but if so, direct your e-mail explicitly to the WG Chair.

The issue that might be unresolved is the one of what ISPs should
do when they get these deprecated attributes.  For me, that is the
subject for another I-D, let's get this one out pronto, but from comments
on the list, I am not sure what the consensus on this is.

Tom Petch

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "iLya" <[email-masked]>
Date: Fri, 18 Feb 2011 12:31:22 +0100

--------------------------------------------------
> on the list, I am not sure what the consensus on this is.

Uhm...we had discussed what ISP's should do when such attribute is 
encountered, though it didn't seem like we've reached an agreement. I 
believe "what to do" should be part of -depricate- draft, rather then going 
into separate document. So let's agree on which of the suggested options to 
adopt and proceed to WGLC.

Cheers,
iLya

---

From: Warren Kumari <[email-masked]>
Date: Fri, 18 Feb 2011 12:05:37 -0500

On Feb 18, 2011, at 5:18 AM, t.petch wrote:

> Yes but who are you poking?

Actually, I wasn't poking any specific person, but rather relying in  
the fact that mentioning last call often entices folk to read the  
draft ;-)

>  I am happy with and would welcome

Fair enough - I was mainly trying to get more views / input, but Sue  
saw it and will be starting LC soon....
W