Subject: Protocol analysis

From: Tony Li <[email-masked]>
Date: Mon, 01 Aug 2005 14:04:59 +0100

This is to kick off the discussion of the protocol analysis document
requirement.

Tony

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

---

From: Tony Li <[email-masked]>
Date: Mon, 01 Aug 2005 17:31:18 +0200

> This is to kick off the discussion of the protocol analysis document

The document is not necessary and should be eliminated from the routing
protocol requirements.

Tony

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 1 Aug 2005 16:41:22 +0100 (BST)

On Mon, 1 Aug 2005, Tony Li <[email-masked]> wrote:
> On Mon, 1 Aug 2005, Tony Li <[email-masked]> wrote:

Tony, do you often hold conversations with yourself? Or is this a
personal/professional opinion thing?

thanks,

L.

> Tony

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Tony Li <[email-masked]>
Date: Mon, 01 Aug 2005 23:23:22 +0200

> personal/professional opinion thing?

Lloyd,

We were trying to separate starting the conversation (as requested in
real-time by an AD) from expressing our opinion.

Regards,
Me, myself, et moi

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 1 Aug 2005 23:26:16 +0100 (BST)

> real-time by an AD) from expressing our opinion.

Well done, that AD.

L.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 01 Aug 2005 15:57:55 -0700

So its probably less work to write the document than to change the rules
so you don't have to write the document but changing the rules has the
added benefit of sparing others the pain in the future.

Admirable.

Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Aug 2005 00:14:23 +0100

> This is to kick off the discussion of the protocol analysis document

Thanks Tony :-)

General point. It is not clear from this document whether it updates,
enhances or replaces RFC1264

Section 2 lists some goals. The first of these is that...
       Ensure that the documentation is adequate for multiple
       interoperable implementations of the technology to be developed
       independently without the need to consult the original authors or
       reverse-engineer an existing implementation.
This is an excellent goal, but I don't see anything measurable in the
process that guarantees this. What we have is section 4.1 requirement 1
that states...
       The
       specification for the routing protocol must be well written such
       that independent, interoperable implementations can be developed
       solely based on the specification.  For example, it should be
       possible to develop an interoperable implementation without
       consulting the original developers of the routing protocol.
What measurement will be used to assess this? It is certainly possible to
use the development of such implementations as evidence, but the absence
of implementations is not contrary evidence.

The second goal...
       Ensure that first-order problems in the technology have been
       discovered and fixed, its basic scaling properties, limitations,
       dynamics, and security aspects have been analysed before it is
       put on the Internet standards track and gets widely deployed.
...is also admirable, but we have no control over the "before it ... gets
widely deployed".
We do have sections 4.2 and 4.3 requirements 5 and 6, but these refer to
the standardisation process and not to the deployment. Since we can only
make recommendations towards the goal, rather than put in place process to
guarantee the goal, we should either revise the goal (strike "and gets
widely deployed") or explicitly fess up that we can't guarantee the goal.

MIB issue number 1
The fourth goal of section 2 is...
       Ensure that it's possible to monitor (and optionally configure)
       the system using an open, standard interface.
a. What is "the System"?
b. We need to jump one way or the other. Either we require MIB
    modules to be developed (section 4.1 requirement 2) or we are
    happy with "an open, standard interface". I think that the agreement
    was that (for now) we go with SNMP - so please change the goal
    accordingly.

MIB issue number 2
I think we agreed in the meeting that we would dilute the MIB module
requirement for protocol extensions "in some way" so that we could allow
batching of minor extensions and avoid proliferation of distinct MIB
modules. This might be covered under the waiver process in section 3.2,
but it currently reads as though this is a highly unusual event.

Section 5 requirement 2
I welcome the requirement for a review by the ROuting Area directorate
(and any other competant parties). But...
- who are the Routing Area Directorate?
- how does a WG chair get a review from them?
- how is the process managed to be timely and appropriate?

Section 5 requirement 3
"...including origin of code"
I cannot believe that all vendors will happily publish the provenance of
their code in a public place.
It must be enough that this information has been disclosed to a third
party (chair or otherwise) to verify that the code comes from different
sources.

Section 6 third bullet
IETF last call is surely too late to comment on whether or not to apply
the rules if there has been a decision to apply the rules (By then, all of
the work to apply the rules has already been done).

Section 8 intentionally left blank :-)
You need to cover:
1. The security requirements and sections that must be added to standards
through this process (just back-pointers) and what the implications of
these procedures are for security in the protocols and the Internet.
2. The scope for the procedures in this draft to be used as a DoS attack
on the standards development process.

Nits:
Section 2 has an unresolved reference to [Huston].
Through-out... please use "MIB module" not "MIB".
Use of RFC2119 notation is inappropriate.
Internet-Draft should be hyphenated throughout.
Sections 4.2 and 4.3 point 6 s/a Exterior/an Exterior/
Section 5.1 point 7 - the URL should probably be provided through a
reference

Cheers,
Adrian