Subject: Final open issues in draft-ietf-ipvbi-nabts-02.txt

From: Dan Zigmond <[email-masked]>
Date: Fri, 14 May 1999 16:21:13 -0700

I apologize for the long silence on the IPVBI mailing list.  The Area
Advisors for our working group have highlighted some concerns in our current
IP over VBI draft.  At first it seemed that these were all relatively minor
and could be handled through editorial corrections, but this now seems to
have been an error in judgement on my part.  Rather than continuing to edit
the draft without involving the rest of the group, I wanted to post a list
of the open issues so others can express their opinions.

Several corrections have already been made to the draft.  These include:
 - clarifying the reference to RFC 1144; we implied before that our 
   header compression was based on that spec, when in fact it bears no 
   more than a family resemblance 
 - clarifying how uncompressed headers are sent
 - using consistent diagrams for all bitfield descriptions
 - adding an IANA considerations section

I believe all of these are uncontroversial, and no comments have been made
to the list about them since the draft was published last month.

A few new issues have now been raised:
 - specifying behavior for sender and receiver of compressed packets (for
   transmission of uncompressed packets as well as how reuse index values)
 - specify what fields in the IP+UDP headers have to match
   for the packet to be considered part of the group such as the TOS bits.
 - The compressed format has a 4 byte UDP checksum field but the UDP
   checksum field is only 2 bytes. What is the intent?
 - Same issue for the IP identification field.
 - The security considerations section states that security can be done
   in the application protocol when in fact we have IPsec, TLS, as well as
   application security. Thus referencing IPsec (and perhaps TLS) would be
   a good thing.

I think all of these are also largely editorial, but I wanted to make sure
to bring the working group as a whole back in the loop before making a pass
at the document.  The first is probably the most difficult, and I'm
surveying the people I know who are using the draft spec to see what they
feel are appropriate values.  I hope to have some guidelines out to the list
soon.

One more serious suggestion has been made:
 - switch to a header compression scheme more closely modeled on RFC 2508

I think this would be a mistake, but I wanted to make sure others in the
group at least had the opportunity to consider it.  The compression scheme
in our draft has been widely used in VBI in North America and has worked
well, and I think making such a radical change to our specification so late
in our process would be too disruptive.  Needless to say, we're already
extremely late, and many in the industry are pushing us to get this out the
door.

I look forward to hearing any thoughts on these issues, and, again, I hope
to have a proposal on sender and receiver behavior for header compression
very soon.

	Dan 

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

---

From: "Carr, Wayne" <[email-masked]>
Date: Thu, 20 May 1999 17:13:35 -0700

I haven't been tracking IPVBI carefully since February.  Back then someone
told me there was a 1500 byte limit on UDP datagram size in IPVBI -- not MTU
size, a UDP datagram size.  I was concerned, checked, and found that wasn't
in the draft.  Someone else just told me that again.  Looking at the spec,
there are changes that lead to confusion about this.

The text says IP Packets take one of two forms. One uncompressed.  One
compressed.  Both show a UDP header as part of the packet and both show a
1472 byte limit on payload size following the UDP header.  The text goes on
to say "All datagrams belonging to a multi fragment IP packet shall be sent
with full headers, in the uncompressed header format."   Neither of the
forms is appropriate for IP fragmentation packets.

What is the intention of this addition?  Has the group voted on an mtu for
IP packets?  There wasn't one in February.  I'd assume this is not trying to
place a vere small limit on UDP datagram size, but that is the way it is
being interpretted by some.

> -----Original Message-----
> From: Dan Zigmond [mailto:[email-masked]]
> Sent: Friday, May 14, 1999 4:21 PM
> To: [email-masked]'
> Subject: Final open issues in draft-ietf-ipvbi-nabts-02.txt
> 
>