Subject: LAST CALL: draft-ietf-ipvbi-nabts-03.txt

From: Dan Zigmond <[email-masked]>
Date: Fri, 18 Jun 1999 14:49:38 -0700

So this is a revision of our latest Internet-Draft, based on the feedback we
received form our Area Directors and reported to the list last month.  I
think it addresses all of the concerns raised, as well as Wayne Carr's
question about MTU.

I would like to re-start our working group last call on this draft today.
Please take some time and look it over, and post to the list any questions
or concerns you have.  If we're all still in agreement, I'd like to send
this to the IESG for consideration as a Standards Track RFC in two weeks, on
July 2nd.

Happy reading.

	Dan

---------------------------------------------------
Dan Zigmond
Senior Manager, Interactive Television Technology
WebTV Networks, Inc.
[email-masked]
---------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 18, 1999 4:15 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ipvbi-nabts-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the IP over VBI Working
Group of the IETF.

	Title		: The Transmission of IP Over the Vertical Blanking 
                          Interval of a Television Signal
	Author(s)	:  R. Panabaker, S. Wegerif, D. Zigmond 
	Filename	: draft-ietf-ipvbi-nabts-03.txt
	Pages		: 20
	Date		: 17-Jun-99

This document describes a method for broadcasting multicast IP data
using the vertical blanking interval of television signals.  It
includes a description for compressing multicast IP headers on
unidirectional networks, a framing protocol identical to SLIP, a
forward error correction scheme, and the NABTS byte structures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipvbi-nabts-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipvbi-nabts-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipvbi-nabts-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-----
To: 
Subject: 
Date: Fri, 18 Jun 1999 12:59:27 -0700
X-Mailer: Internet Mail Service (5.5.2448.0)

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 18 Jun 1999 18:24:34 -0400

Dan,

Dont want to be a pain, but can you point me to an archive of
discussions surrounding the WG's thoughts on using compressed
HDLC-like framing (as per PPP) instead of SLIP, and the longer
term goal (or non-goal) of being able to interleave high priority
tiny-grams within longer IP packets? (e.g. Real Time Framing
extensions to PPP/HDLC in draft-ietf-issll-isslow-rtf-05.txt can
do this, nothing equivalent is defined for SLIP, ... )

I'm sure the discussions been had, I just can't find record of it.
I might even suggest it be captured in an appendix to the I-D
since others are bound to wonder (in the future) about the
choice of non-standard SLIP :)

(Note, I'm only referring to PPP encaps/framing rather than
using PPP state machines which I recognize cannot be deployed
easily due to the uni-directional nature of the link...)

My intrigue is aroused because I observe that HDLC-like
framing can be reduced to simple FS delimiters (equivalent
to SLIP's END byte) and an Escape byte for when FS delimiters
appear in the data stream. Same overhead as SLIP, but more
widely implemented. Your use of 1 and 2 octet 'schema'
fields preceding the user packet is pretty much the same as
the PPP Protocol Field space (which is already administered
by IANA I believe). You could get a new PPP protocol field value
assigned to represent what you currently call Schema 0. Other
schemas can be developed and assigned their own code points.
A 32 bit HDLC-like FCS might replaced the current 32 bit CRC.
The nett effect is to reduce the number of codepoint spaces
managed by IANA, for little to no in-band additional overhead
(I'm madly waving my hands a little at this point by assuming
we can ditch the HDLC Addr/Control pre-header 0xFF03 too).

Of course, I've probably missed some key 'gotcha' here :)

cheers,
gja

> this to the IESG for consideration as a Standards Track RFC in two weeks, on

________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs, Lucent Technologies