Re: IANA Considerations for RSVP

[Scott W Brim <sbrim@cisco.com>]

On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge allegedly wrote:
> John,
> Hmmm... a bit IETF centric.
> Because some portion of a problem space touches or uses an IETF protocol,
> then clearly the entire problem must belong to IETF.

The entire problem of signing off on extensions to the protocol does
belong to the IETF, if you want them to be used outside of some local
network.  That's for architectural consistency.

> Consider that the ASON architecture encompasses transport networks where
> what we call the transport plane (IETF calls the data plane) is not
> necessarily IP. What if the addresses are NSAP addresses instead of IP
> addresses? What if some or all of the signaling links employ PNNI
> as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
> all belong to IETF? These are problems that cannot be solved without
> good cooperation between the standards organizations that are involved.

The IETF is responsible for defining the mechanisms by which those
non-IP addresses can be carried in the IP-based protocol.

> In terms of the existance of a communication channel and procedures for
> collaborating between IETF and ITU-T, this exists but perhaps, in spite
> of receiving these liaisons, you have not taken the trouble to become
> familiar with it. Identical text describing the collaboration process is
> published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We are following
> the documented process, and this suggests a different answer than your
> emails to the question of which side of this communication channel is
> not holding up their end.

I agree the communication channels could be used better.  I also think
that the best way to communicate is probably NOT those channels, but
rather to bring in parallel technical contributions in each group, to
make sure they are in sync.  Take the ideas through the procedures that
participants actually care about.

swb