Subject: [Idr] Movement of draft-ietf-idr-operational-00.txt message to DEAD Status (2/1 to 2/15)

From: "Susan Hares" <[email-masked]>
Date: Thu, 2 Feb 2017 15:01:53 -0500

On November 20th, 2016 Job ask the WG chairs to change the status of draft-ietf-idr-operational-00.txt to DEAD.   This begins a 2 week WG action call for the action of moving draft-ietf-idr-operational-00.txt to dead (2/1 to 2/15).   In your comments, please indicate any benefits or problems with moving this IDR draft to dead. 

At IETF 97,  John Scudder indicate that the chairs would be querying the WG regarding Zombie drafts - that is drafts with no substantial action for over 3 years.  While draft-ietf-operational-message-00.txt fits the Zombie status, this call to move the draft to dead is being handled separately from other Zombie drafts.  

If you have any questions about what it means to move an IDR draft to "DEAD",  you may either ask on the list or send the WG chairs a message. 

Sue Hares 

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2017 10:52 AM
To: Hares Susan
Subject: Fwd: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line in the peer's syslog at shutdown

Here's one more thing for us to think about:

"I'd like to ask the chairs to move 'draft-ietf-idr-operational-message-00' to 'Dead' status"

(Near bottom of message). When he asked, IIRC I told him "we'll attend to that in the new year". I suppose we should attend to it at some point.

—John

> Begin forwarded message:
> 
> From: Job Snijders <[email-masked]>
> Subject: Re: [Idr] [GROW] draft-snijders-idr-shutdown-00: Drop a line 
> in the peer's syslog at shutdown
> Date: November 20, 2016 at 5:09:15 AM EST
> To: Robert Raszuk <[email-masked]>
> Cc: [email-masked], [email-masked]
> 
> On Sat, Nov 19, 2016 at 03:57:06PM +0100, Robert Raszuk wrote:
>> I am not going to argue with few of you here who want free form text 
>> and do not accept any suggestions.
> 
> No, we are just selective in which suggestions we accept. Suggestions 
> falling short of the mark are countered and discarded.
> 
>> But if you can not parse few defined keywords in any free form text 
>> to enable better automated interpretation of the message I think 
>> there is more problems here.
> 
> This proposal aims to accomplish a simple thing, which is to enrich an 
> event with additional contextual information and assist in triaging 
> ("This is unexpected, is this a problem?" "Should we embark on a 
> specific procedure?") in an operator-centric workflow. By keeping it 
> free form, it allows enough space to experiment with structured 
> inter-domain signaling, and if operators find this useful a dictionary 
> of messages can be offered at a later date as an extension based on 
> operational experience.
> 
> It is absolutely is not aiming to act as a generic inter-domain 
> signaling protocol for operations orchestration.
> 
>> TLV within current NOTIFICATION MSG is an overkill so do not count of 
>> new proposal from me on it.
> 
> Hence this is not TLV, this is LV, already explained here:
> https://www.ietf.org/mail-archive/web/idr/current/msg17127.html
> 
>> Operational message solved that already.
> 
> Operational message expired in September 2012, and as such I do not 
> consider it an active working group document anymore.
> 
> The Operational message does not provide a strong correlation between 
> a Cease event and some type of additional meta-data. Same reason why 
> 'advisory' and 'shutdown' do not preclude each other.
> 
> I'd like to ask the chairs to move 'draft-ietf-idr-operational-message-00' to 'Dead' status.
> 
>> Btw how are you going to handle it in IX ? I assume RS peers will not 
>> get any info if one of the parties they used to get routes from goes 
>> down and sends free form msg to RS ? Routes will be get withdrawn and 
>> that's it.
> 
> Correct. This is the expected behaviour.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr