Subject: RE: Progressing: draft-farrel-rtg-manageability-requirements-01.txt

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Thu, 10 Nov 2005 14:41:59 -0500

I agree w/ Jerry's comment and in-favor of this draft. 

Thanks

Regards... Zafar 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Ash, Gerald R (Jerry), ALABS
> Sent: Thursday, November 10, 2005 2:21 PM
> To: Adrian Farrel; [email-masked]
> Cc: Loa Andersson; Ash, Gerald R (Jerry), ALABS; Avri Doria
> Subject: RE: Progressing: 
> draft-farrel-rtg-manageability-requirements-01.txt
> 
> > Should we advance this work as a suggestion or BCP, or 
> should we throw 
> > it out?
> 
> IMO we should advance to BCP, and require a manageability section.
> Requiring the section will force the authors to give 
> thoughtful consideration to what the manageability 
> requirements are for the feature.
> 
> Thanks,
> Jerry
> 
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/routing-discussion
> 

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 11 Nov 2005 17:50:42 +0100

I agree and am in favour.

Tom Petch

----- Original Message -----
From: "Zafar Ali (zali)" <[email-masked]>
To: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>; "Adrian Farrel"
<[email-masked]>; <[email-masked]>
Cc: "Loa Andersson" <[email-masked]>; "Avri Doria" <[email-masked]>
Sent: Thursday, November 10, 2005 8:41 PM
Subject: RE: Progressing: draft-farrel-rtg-manageability-requirements-01.txt

Thanks

Regards... Zafar

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Nov 2005 21:01:33 -0000

Attention ADs.

I wouldn't claim overwhelming support, but I would also note that the only
issues raised so far were by you at the meeting in Vancouver.

So where do we go from here?

We originally positioned this as Informational, but making firm
requirements.

My suggestion, in response to your concerns in Vancouver was to keep this
as Informational, but drop the requirements making the Manageability
Concerns section advisory.

The small email exchange on the list, however, is requesting BCP status
with firm requirements.

Do you want to give some guidance and enter into a discussion?

Cheers,
Adrian

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 19 Nov 2005 10:45:01 -0500

In message <00dd01c5ecf0$045f0750$fb849ed9@Puppy>
"Adrian Farrel" writes:
>  
> Attention ADs.
>  
> I wouldn't claim overwhelming support, but I would also note that the
> only issues raised so far were by you at the meeting in Vancouver.
>  
> My suggestion, in response to your concerns in Vancouver was to keep
> this as Informational, but drop the requirements making the
> Manageability Concerns section advisory.
>  
> The small email exchange on the list, however, is requesting BCP
> status with firm requirements.
>  

Adrian,

It makes no sense to try to mandate something in an informational
draft.

If you mandated this structure most routing protocols would have to
cite the same link liveness and host liveness protocols and how they
interact plus the mechanisms of the protocol itself.

If there is a set of routing protocol for which management is not
widely enough understood, having a separate informational draft would
be good.  Otherwise to be complete this would be a very big section.

For example, in addition to MIB you missed XML.  Do you cite the DTD
and a sample XLST?  Is there such a things as a common XML DTD across
vendors (I think not)?  If a routing protocol was written prior to the
use of XML for management would that preclude using XML or require a
new iteration of each routing protocol?

I think it is a mistake to put in a "how to run your network" tutorial
in each routing protocol.  So far operations practices have changed
independently of iterations of the routing protocol itself.  Even
implememtation changes such as coupling with link liveness and
neighbor liveness detection occur independently of the routing
protocol itself.  Coupling the routing protocol with management of the
routing protocol by putting it in the same document would be a
mistake.

Curtis