Opened 11 years ago

Closed 11 years ago

#133 closed defect (fixed)

Dave's Review

Reported by: bernard_aboba@… Owned by: bernard_aboba@…
Priority: major Milestone: milestone1
Component: draft-iab-extension-recs Version: 1.0
Severity: In WG Last Call Keywords:
Cc:

Description

A marked up copy with my comments is now at
http://research.microsoft.com/~dthaler/draft-iab-extension-recs-11.pdf

I see that at least one of my comments was the same as Joel's.

Also there's two topics that I didn't see covered that I was thinking about.
They could either be added to this document, or left for some other doc
(I have no preference):
1) What's an extension vs a higher/lower-layer protocol? For example,

is a new crypto algorithm really an extension to a protocol defined to
use GSSAPI? Is a congestion control algorithm really a TCP extension
if TCP is designed to be pluggable (analogous to GSSAPI)?

2) When should an extension document be labeled to Update the base,

Obsolete the base, or neither. This is tightly tied to the first question
in actuality. And we have problematic examples (e.g., IGMPv3 incorrectly
obsoletes the IGMPv2 RFC, and then normatively references it for
required behavior that isn't in the IGMPv3 RFC).

[Brian Carpenter]:

Also there's two topics that I didn't see covered that I was thinking about.
They could either be added to this document, or left for some other doc
(I have no preference):

My preference is to leave them. Honestly the debate is endless.

1) What's an extension vs a higher/lower-layer protocol? For example,

is a new crypto algorithm really an extension to a protocol defined to
use GSSAPI? Is a congestion control algorithm really a TCP extension
if TCP is designed to be pluggable (analogous to GSSAPI)?

2) When should an extension document be labeled to Update the base,

Obsolete the base, or neither. This is tightly tied to the first question
in actuality. And we have problematic examples (e.g., IGMPv3 incorrectly
obsoletes the IGMPv2 RFC, and then normatively references it for
required behavior that isn't in the IGMPv3 RFC).

In particular, this one is IESG territory, not IAB.

[Spencer Dawkins]

Hi, Dave,

I think both of these topics are worthy of noodling.

I think the first topic is a good candidate for IAB noodling. I would also be fine with a separate document.

I'm confused about whether the second topic is a candidate for IAB noodling (because we have oversight of standards process, and/or the RFC series), IESG noodling (I'm guessing, because the vast majority of documents affected would be IETF-stream documents), or joint noodling (because most, but not all, the documents affected are IETF-stream documents).

Could you share your thoughts about that? I'm not expressing an opinion, just trying to make sure I understand what you are thinking.

Thanks,

Spencer

[Dave Thaler]

Sure, here's my thoughts...

No document should ever have a normative reference to something it obsoletes.
I think that should be a hard rule. So in the IGMPv3 example, it should have
Updated igmpv2, or else incorporated the relevant text into the igmpv3 doc
in order to obsolete it.

A document Updates another document if an implementation of the original
would typically need to be updated. If the original was designed with a modular
interface (along the lines of GSS-API for instance) then a document can be
independent and not Update the original spec (at least for this reason anyway).
One could argue that this approach could be taken with TCP congestion control
algorithms for instance.

Attachments (1)

draft-iab-extension-recs-12.txt (100.6 KB) - added by bernard_aboba@… 11 years ago.
Extension recommendations -12 final

Download all attachments as: .zip

Change History (8)

comment:1 Changed 11 years ago by bernard_aboba@…

I have modified Section 2.2 to address the update issue. IMHO, this issue is important because extensions modifying the base protocol without an Updates: header, may not receive the appropriate level of review.

Here is the proposed text:

Extension designers should examine their design for the following
issues:

  1. Modifications or extensions to the underlying protocol. An extension document should be considered to update the underlying protocol specification if an implementation of the underlying protocol would need to be updated to accomodate the extension. This should not be necessary if the underlying protocol was designed with a modular interface. Examples of extensions modifying the underlying protocol include specification of additional transports (see Section 4.6), changing protocol semantics or defining new message types that may require implementation changes in existing and deployed implementations of the protocol, even if they do not want to make use of the new functions. A base protocol that does not uniformly permit "silent discard" of unknown extensions may automatically enter this category, even for apparently minor extensions. Handling of "unknown" extensions is discussed in more detail in Section 4.7.

comment:2 Changed 11 years ago by bernard_aboba@…

  • Owner changed from bernard_aboba@… to dthaler@…

Changed 11 years ago by bernard_aboba@…

Extension recommendations -12 final

comment:3 Changed 11 years ago by bernard_aboba@…

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 11 years ago by bernard_aboba@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:5 Changed 11 years ago by bernard_aboba@…

Here are the proposed changes:

Section 3.7:

3.7. Extensions to Critical Protocols

Some protocols (such as Domain Name Service (DNS), Border Gateway
Protocol (BGP), Hypertext Transfer Protocol (HTTP)) or algorithms
(such as congestion control) have become critical components of the
Internet infrastructure. A critical component is one whose failure
can lead to Internet-wide reliability and security issues or
performance degradation. When such protocols or algorithms are
extended, the potential exists for negatively impacting the
reliability and security of the global Internet.

As a result, special care needs to be taken with these extensions,
such as taking explicit steps to isolate existing uses from new ones.
For example, this can be accomplished by requiring the extension to
utilize a different port or multicast address, or by implementing the
extension within a separate process, without access to the data and
control structures of the base protocol.

Experience has shown that even when a mechanism has proven benign in
other uses, unforeseen issues may result when adding it to a critical
protocol. For example, both ISIS and OSPF support opaque Link State
Attributes (LSAs) which are propagated by intermediate nodes that
don't understand the LSA. Within Interior Gateway Protocols (IGPs),
support for opaque LSAs has proven useful without introducing
instability.

However, within BGP, 'attribute tunneling' has resulted in large
scale routing instabilities, since remote nodes may reset the LOCAL
session if the tunneled attributes are malformed or aren't
understood. This has required modification to BGP error handling, as
noted in "Error Handling for Optional Transitive Attribute BGP
Attributes" [I-D.ietf-idr-error-handling].

In general, when extending protocols with local failure conditions,
tunneling of attributes that may trigger failures in non-adjacent
nodes should be avoided. This is particularly problematic when the
originating node receives no indicators of remote failures it may
have triggered.

Section 4.1:

  1. Assumed backward compatibility. In this approach, implementations may send packets with higher version numbers to legacy implementations supporting lower versions, but with the assumption that the legacy implementations will interpret packets with higher version numbers using the semantics and syntax defined for lower versions. This is the approach taken by "Port-Based Network Access Control" [IEEE-802.1X]. For this approach to work, legacy implementations need to be able to accept packets of known types with higher protocol versions without discarding them; protocol enhancements need to permit silent discard of unsupported extensions; implementations supporting higher versions need to refrain from mandating new features when encountering legacy implementations.

Section 4.6:

4.6. Transport

In the past, IETF protocols have been specified to operate over
multiple transports. Often the protocol was originally specified to
utilize a single transport, but limitations were discovered in
subsequent deployment, so that additional transports were
subsequently specified.

In a number of cases, the protocol was originally specified to
operate over UDP, but subsequent operation disclosed one or more of
the following issues, leading to the specification of alternative
transports:

  1. Payload fragmentation (often due to the introduction of extensions or additional usage scenarios);
  1. Problems with congestion control, transport reliability or efficiency;
  1. Lack of deployment in multicast scenarios, which had been a motivator for UDP transport.

On the other hand, there are also protocols that were originally
specified to operate over reliable transport that have subsequently
defined transport over UDP, due to one or more of the following
issues:

  1. NAT traversal concerns that were more easily addressed with UDP transport;
  1. Scalability problems, which could be improved by UDP transport.

Since specification of a single transport offers the highest
potential for interoperability, protocol designers should carefully
consider not only initial but potential future requirements in the
selection of a transport protocol. Where UDP transport is selected,
the guidance provided in "Unicast UDP Usage Guidelines for
Application Designers" [RFC5405] should be taken into account.

After significant deployment has occurred, there are few satisfactory
options for addressing problems with the originally selected
transport protocol. While specification of additional transport
protocols is possible, removal of a widely used transport protocol is
likely to result in interoperability problems and should be avoided.

Mandating support for the initially selected transport protocol,
while designating additional transport protocols as optional may have
limitations. Since optional transport protocols are typically
introduced due to the advantages they afford in certain scenarios, in
those situations implementations not supporting optional transport
protocols may exhibit degraded performance or may even fail.

While mandating support for multiple transport protocols may appear
attractive, designers need to realistically evaluate the likelihood
that implementers will conform to the requirements. For example,
where resources are limited (such as in embedded systems),
implementers may choose to only support a subset of the mandated
transport protocols, resulting in non-interoperable protocol
variants.

comment:6 Changed 11 years ago by bernard_aboba@…

  • Owner changed from dthaler@… to bernard_aboba@…
  • Status changed from reopened to new

comment:7 Changed 11 years ago by bernard_aboba@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.