Re: TCP Mapping

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

> Hong and I have already exchanged private messages on this topic.  I'll
> repeat what I said here.

So ... Did you decide mutually to re-conduct the prior private exchange
on an IETF list?

> First, I do expect to have to edit the TCP draft slightly to address some
> comments I received from members of the IESG.  That won't happen until after
> IETF-54.

If the comments from non-contributor IESG reviewers are editorial in nature,
then the editorial delta is a non-event. If they are substantive in nature,
say replace tcp with sctp (example of substantive proposed change), then the
contributors need to determine if there is consensus to adopt any of the
changes.

> Second, I'm very much against putting application-layer semantics into the
> layer above TCP -- it smells like a layering violation to me.  I explicitly
> added an <extension> element as a child of the <epp> element to support
> adding features like data pushing from the "server" -- that's where I think
> such extensions belong.  Plus, it's not wise to believe that EPP messages
> aren't likely to exceed a certain length based on experiences with domain
> name provisioning.  There may well be other operating environments where all
> 32 bits (and maybe even more -- I gave some serious thought to a 64-bit
> length field in the header) are needed.  Being short-sighted now means we're
> going to have issues in the future.

The proposal was vague, no delta of schema, no delta of text. That said, the
proposal revisited the Ethernet vs 802.3 overloading of type-as-length. 

No thanks.

> Third, this whole pushing thing may be a better candidate for implementation
> using BEEP.  If that's true, it doesn't belong in the TCP draft at all.

Actually, the peer- vs client- (event model) isn't dependent upon the
transport protocol (tcp or beep/{tcp,...}, but ... pragmatically, it doesn't
belong in any draft grounded on working group consensus -- unless most
everyone actually contributing have had a profound change of mind.

> I've already started work on a draft document describing how to properly
> extend the protocol, and I expect -00 to be ready some time after the
> Yokohama meeting.  I think it will be far easier to deal with extension
> drafts _after_ we have the mechanics documented a bit better.

Good.

Cheers,
Eric
> 
> -Scott-
> 
> > -----Original Message-----
> > From: Liu, Hong [mailto:Hong.Liu@neustar.biz]
> > Sent: Friday, June 28, 2002 5:55 PM
> > To: 'ietf-provreg@cafax.se'
> > Subject: TCP Mapping
> > 
> > 
> > Scott,
> > 
> > I would like to know whether it is still possible to make 
> > changes to the TCP
> > mapping document at this point. We have been working on a 
> > draft for EPP TCP
> > PUSH extension, as we promised before. Sorry, we missed the 
> > -00 deadline
> > this time...
> > 
> > There are a number of ways to do it, but we find it the 
> > simplest to use the
> > Total Length header of the EPP datagram in the TCP mapping to 
> > differentiate
> > the server-pushed message from other messages. We are 
> > considering using only
> > the highest bit in the header, but maybe a better way is to 
> > reserve the
> > highest octet for other extensions. EPP messages do not need 
> > 2^32-1 octects,
> > 2^24-1 should be sufficiently large. What do you think?
> > 
> > We would also like to hear from you and others on the list about other
> > alternatives. Thanks!
> > 
> > --Hong
> >