Re: Procedural question (Re: SIP API spec)

Paul Tsuchiya <> Wed, 27 January 1993 17:40 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa08101; 27 Jan 93 12:40 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08097; 27 Jan 93 12:40 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa18213; 27 Jan 93 12:42 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29185; Wed, 27 Jan 93 09:41:17 PST
Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02248; Wed, 27 Jan 93 09:42:30 PST
Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA20435; Wed, 27 Jan 93 09:41:02 PST
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA03636; Wed, 27 Jan 93 09:42:28 PST
Received: from by Sun.COM (4.1/SMI-4.1) id AA29124; Wed, 27 Jan 93 09:41:00 PST
Received: from by (4.1/4.7) id <AA24593> for ip-encaps@sunroof.Eng.Sun.COM; Wed, 27 Jan 93 12:38:46 EST
Received: by (4.1/4.7) id <AA05012> for; Wed, 27 Jan 93 12:38:44 EST
Date: Wed, 27 Jan 93 12:38:44 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Tsuchiya <>
Message-Id: <>
Subject: Re: Procedural question (Re: SIP API spec)
Content-Length: 1406

>  	What I'd like to suggest is that this document serve that purpose:
>  instead of referencing SIP specifically, we could refer to a "Better
>  Internet Protocol (BIP)" and only refer to specific proposals as needed.
>  	Before getting down to the details on how this would affect the spec,
>  I thought I'd just mention this idea first to see what the general consensus
>  was..

To the extent that one can find commonality between the
various proposals, I agree completely with your goal above.

I think in both the API and transition scheme, Pip and SIP
match reasonably well.  On our API, we have a local 32 bit
identifier, but were still leaning towards passing the Pip
ID across the interface, as this is something that won't
change even as addresses change.  But, we've considered
not passing the Pip ID.

It seems that if we can come up with an API that works 
equally well for Pip and SIP and CLNP, then we are on the
right track towards generality, and therefore evolution
(a stated Pip goal!!!).

But, even if other folks don't think it is a good idea
to have common specs between the various proposals, we
here in the Pip shop have no qualms about plagerising
whatever other work applies to Pip (as Bob Hinden discovered
with the requirements evaluation doc..... :-) the best interests of the community, of course......

.......and with attribution, of course........