Joel's Review

[Bernard_Aboba@…]

In my opinion, this document is probably ready for publication as an Informational RFC. (I.e., I can live with it if it goes out as is, but wonder if a few changes may help it.)

I do have a few comments, which might be worth minor edits (or might not even be worth that).

In discussing profiling, the text says that profiles which upgrade normative requirements are typically only necessary if the protocol is ill-defined. However, there is another class of cases. Some profiles are built to meet specific operational requirements. So vendor or consortium profiles may require certain features which are optional in the RFCs. Security organizations or consortia may require certain stronger cryptographic mechanisms than the RFC mandates.

There is an apparent conflict between the discussion of X-/P- headers and the discussion of experimental code points. (The are basically the same thing, but one is discouraged and one is permitted.) I think that the reason for the difference is that the experimental code point spaces are small, so collision is likely, discouraging accidental wide-spread deployment? Whatever the explanation for the difference, it would seem useful to say something.

Why is the "Design for deployability. This includes understanding what current implementations do..." in the Considerations for the base protocol? Is the point that one needs to consider the design of the devices that will implement the protocol? The text here seems to talk about proposed extensions, while the section seems to be how to design the base protocol so that extensions can be safely made later. Some of the other bullets here seem to edge into having the same confusion.

Yours,
Joel

[Brian Carpenter]

Joel, thanks for the comments.

On 2012-02-26 14:36, Joel M. Halpern wrote:

In my opinion, this document is probably ready for publication as an
Informational RFC. (I.e., I can live with it if it goes out as is, but
wonder if a few changes may help it.)

I do have a few comments, which might be worth minor edits (or might not
even be worth that).

In discussing profiling, the text says that profiles which upgrade
normative requirements are typically only necessary if the protocol is
ill-defined. However, there is another class of cases. Some profiles
are built to meet specific operational requirements. So vendor or
consortium profiles may require certain features which are optional in
the RFCs. Security organizations or consortia may require certain
stronger cryptographic mechanisms than the RFC mandates.

I guess there's a difference between profiles that are really upgrades
to the interoperability spec, and profiles that are deployment cookbooks.

Those of us who burned their fingers on OSI deployment know that
the need for profiles is generally a sign of interoperability defects
(and in fact led to mutually non-interoperable OSI deployments).
But some profiles are only deployment aids. This could be noted.

There is an apparent conflict between the discussion of X-/P- headers
and the discussion of experimental code points. (The are basically the
same thing, but one is discouraged and one is permitted.) I think that
the reason for the difference is that the experimental code point spaces
are small, so collision is likely, discouraging accidental wide-spread
deployment? Whatever the explanation for the difference, it would seem
useful to say something.

Yes, the ones like X- are completely open-ended and I think that is a real
difference from the finite ones like DSCPs. Again, this could be noted.

Why is the "Design for deployability. This includes understanding what
current implementations do..." in the Considerations for the base
protocol? Is the point that one needs to consider the design of the
devices that will implement the protocol? The text here seems to talk
about proposed extensions, while the section seems to be how to design
the base protocol so that extensions can be safely made later. Some of
the other bullets here seem to edge into having the same confusion.

I'm not sure how to completely clarify this. When you design an extensibility
mechanism, you're bound to have a mental model of some kind of what an
actual extension would look like. And thinking about the implementation
would also help. (If we'd done that better with IPv6, surely we'd never
have defined such a beast as the hop-by-hop option.)

[Joel]

Thanks Brian.
I certainly remeber the OSI profiles (I actually worked on some at the NIST OIWs.) You got my point on both of the first two issues.

On the comment in design considerations, the problem I think is merely one of wording. When I see "understand current implementations", tht edoes not usually translate for me into "think about the way the spec will be implemented." I am also not sure, in terms of spec design, that we have a particularly good track record. The IPv6 design claimed to be doing exactly that.

[bernard_aboba@…]

Moved discussion of deployability from Section 4 to Section 3.3 which now reads:

3.3. Architectural Compatibility

Since protocol extension mechanisms may impact interoperability, it
is important that they be architecturally compatible with the base
protocol.

This includes understanding what current implementations do and how a
proposed extension will interact with deployed systems. Is it clear
when a proposed extension (or its proposed usage) will operationally
stress existing implementations or the underlying protocol itself if
widely deployed? If this is not explained in the base protocol
specification, is this covered in an extension design guidelines
document?

Changed the text of Section 3.4.1 as follows:

3.4.1. Profiles

Profiling is a common technique for improving interoperability within
a target environment or set of scenarios. Generally speaking, there
are two approaches to profiling:

a) Removal or downgrading of normative requirements (thereby creating
potential interoperability problems);

b) Elevation of normative requirement levels (such as from a
MAY/SHOULD to a MUST). This can be done in order to improve
interoperability by narrowing potential implementation choices (such
as when the underlying protocol is ill-defined enough to permit non-
interoperable yet compliant implementations), or to meet specific
operational requirements (such as enabling use of stronger
cryptographic mechanisms than those mandated in the specification).

While approach a) is potentially harmful, approach b) may be
beneficial.