Subject: Re: draft-yevstifeyev-netblt-iana-00.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 02 Jan 2011 11:43:01 +0200

John, all,

I have read the document you mentioned (MIL-STD-.....). And the only 
thing I found interesting on these 111 pages is that the port number 1 
is used for TACO2 and what mentioned in section 6.2 of it.

As for White's draft. If he could kindly allow me to be the co-author of 
the document, I would like to work on this document.

So, as I have applied for adopting my drafts as WG items, I ask to 
mention the corresponding port number (1) for TACO2 in 
/draft-yevstifeyev-netblt-iana/ while publishing it as WG draft (if that 
would be approved).

All the best,
Mykyta Yevstifeyev

28.12.2010 18:54, John C Klensin wrote:
> Mykyta,
>
> Are you aware of NetBLT actually being in active use in the
> public Internet, in the form documented in RFC 998?  I'm not,
> but that sort of transport protocol isn't something I've paid
> careful attention to in many years.
>
> John C C White's 1997 Internet-Draft,
> http://tools.ietf.org/html/draft-white-protocol-stack-00,
> suggests that, in its original form, NetBLT contained some
> defects that made it undesirable in practice.  That draft also
> suggested an update that would align NetBLT with then-current
> practice in some private (in this case military) network
> applications.  As far as I can tell, that update never went
> anywhere in the IETF, but that is (sadly) typical of such things
> if no one is pushing for it.
>
> Especially if there is not significant evidence of its being in
> active use in RFC 998 form on the public Internet, it might be
> worthwhile to combine your effort to get the IANA registry in
> order with some version or variation on John's draft so as to
> bring the protocol itself up-to-date.
>
> The information on the standard to which John referred is at
> http://www.gwg.nga.mil/ntb/baseline/docs/44500/index.html; it
> doesn't appear to have changed much since his draft was produced.
>
> Even if it isn't useful to try to publish an updated version of
> the specification, it would probably be desirable to get any
> non-998 values used by the military standard into the registry
> as well.
>
> I've copied John on this note.  Since I don't know if he is
> still at MITRE, I've also copied what is possibly his current
> address based on a web search.  I have no idea whether he would
> still be interested, but he should at least be aware that I'm
> suggesting another look at his 13+ year old work.
>
> best regards and best new year's wishes to both of you,
>      john

---

From: John C Klensin <[email-masked]>
Date: Sun, 02 Jan 2011 13:24:29 -0500

Mykyta,

This is very encouraging.  Thanks.

best new year's wishes,
   john

--On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev
<[email-masked]> wrote:

> John, all,
> 
> I have read the document you mentioned (MIL-STD-.....). And
> the only thing I found interesting on these 111 pages is that
> the port number 1 is used for TACO2 and what mentioned in
> section 6.2 of it.
> 
> As for White's draft. If he could kindly allow me to be the
> co-author of the document, I would like to work on this
> document.
> 
> So, as I have applied for adopting my drafts as WG items, I
> ask to mention the corresponding port number (1) for TACO2 in
> /draft-yevstifeyev-netblt-iana/ while publishing it as WG
> draft (if that would be approved).
> 
> All the best,
> Mykyta Yevstifeyev
> 
>> anywhere in the IETF, but that is (sadly) typical of such
>> things if no one is pushing for it.
>> 
>> Especially if there is not significant evidence of its being
>> in active use in RFC 998 form on the public Internet, it
>> might be worthwhile to combine your effort to get the IANA
>> registry in order with some version or variation on John's
>> draft so as to bring the protocol itself up-to-date.
>> 
>> Even if it isn't useful to try to publish an updated version
>> of the specification, it would probably be desirable to get
>> any non-998 values used by the military standard into the
>> registry as well.
>> 
>> address based on a web search.  I have no idea whether he
>> would still be interested, but he should at least be aware
>> that I'm suggesting another look at his 13+ year old work.
>>

---

From: John White <[email-masked]>
Date: Mon, 3 Jan 2011 08:52:56 -0500

Hi John et al -

Thanks for tracking me down. I retired 5+ years ago, and certainly never expected to give NETBLT another serious thought.

As you have figured out, my main interest in NETBLT was to use it as the core of the TACO2 protocol stack, whose purpose was to move large messages (images) over low-bandwidth, mostly slow-turnaround half-duplex links. At least 3 independent implementations of TACO2 were built, and they were extensively tested for interoperability, so I believe that the specifications in the MIL-STD and the internet draft are pretty complete. I don't know whether anyone is still using TACO2, but I'm inclined to suspect not.

Around the time of the internet draft, I had a conversation with Allison Mankin, who was then something like director of the transport area for the IESG. One concern she expressed was that NETBLT could be a bandwidth hog, to the disadvantage of other protocol streams. For our application that wasn't a problem (it was a feature, actually), and it's not clear to me that it's a transport layer issue, but it certainly could be a problem elsewhere and deserves some thought.

I'd certainly be happy to see someone else take up NETBLT as a project, and will gladly offer whatever support I can as long as it doesn't require me to do any actual work!

Regards, and happy new year to you all,
-John-

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Jan 2011 10:49:11 -0500

--On Monday, January 03, 2011 08:52 -0500 John White
<[email-masked]> wrote:

> Hi John et al -
> 
> Thanks for tracking me down. I retired 5+ years ago, and
> certainly never expected to give NETBLT another serious
> thought.

Probably a special case of the principle that no good deed goes
unpunished. :-)

> As you have figured out, my main interest in NETBLT was to use
> it as the core of the TACO2 protocol stack, whose purpose was
> to move large messages (images) over low-bandwidth, mostly
> slow-turnaround half-duplex links. At least 3 independent
> implementations of TACO2 were built, and they were extensively
> tested for interoperability, so I believe that the
> specifications in the MIL-STD and the internet draft are
> pretty complete. I don't know whether anyone is still using
> TACO2, but I'm inclined to suspect not.
> 
> Around the time of the internet draft, I had a conversation
> with Allison Mankin, who was then something like director of
> the transport area for the IESG. One concern she expressed was
> that NETBLT could be a bandwidth hog, to the disadvantage of
> other protocol streams. For our application that wasn't a
> problem (it was a feature, actually), and it's not clear to me
> that it's a transport layer issue, but it certainly could be a
> problem elsewhere and deserves some thought.

I assume Allison is following the TSVWG mailing list, but have
copied her on this note just in case (and since I'm not on that
list).

> I'd certainly be happy to see someone else take up NETBLT as a
> project, and will gladly offer whatever support I can as long
> as it doesn't require me to do any actual work!

Thanks.  This sort of thing is very much not in my area of
specialty, but I wanted to try to be sure that all possible
connections were made if Mykyta is inclined to do the work to
pursue this.  In particular, it seemed to be that, if we were
going to update the registries to reflect the protocol, we
should know its current status and, if someone (presumably
Mykyta) is willing to do the bulk of the work, to update the
base document accordingly.

Allison, given John White's description of the objectives of
TACO2, would there be any advantage of passing this work by the
Delay Tolerant RG?   Has that been done already?

Best new year's wishes,
    john

---

From: Bob Braden <[email-masked]>
Date: Mon, 03 Jan 2011 10:28:06 -0800

>> problem elsewhere and deserves some thought.

Astonishing discussion.  Another of those ideas that never completely 
dies...

Indeed. Netblt was developed purely as an experiment by Dave Clark, who 
has never encouraged its propagation outside the ivory towers of 
Computer Science. It was mulled over by the End2end Task Force (and it 
undoubtedly appears in E2E meeting minutes from that era).

Put simply, netblt is about was TCP-unfriendly as you can get.  Widely 
used, it would have made a DDoS attack on the entire Internet (at least 
as the Internet existed at that time).  My advice is, leave the Genie in 
the bottle!  Better to spend your time bringing T/TCP back from the dead 
;-))

Bob Braden

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 04 Jan 2011 07:55:08 +0200

Hello all,

Let me inform you about the issues connected with my drafts.

Firstly, I have contacted the authors of draft-ietf-tsvwg-iana-ports to 
ask them to include the registration procedures for RDP, NetBLT and IRTP 
ports. Unfortunately, I have received the response mentioning that these 
protocols are not in use and are rather candidates for historic protocol 
. I may agree partly with this, only for IRTP. For the others, I insist 
on including corresponding entries in the document.

As for NETBLT. We managed to contact John White, the author of NETBLT 
draft (as I remember, draft-white-protocol-stack) (you may see his 
message at the end), that supposed that he is interested somebody would 
take such work. as I mentioned before, I would like to work on this 
draft. As for this, I would inform you about these issues later. 
Nevertheless, we have received a number of messages supposing that 
NETBLT should be historic rather than standards track. One of such 
messages is below. I may disagree that specifying NETBLT will cause 
great harm to Internet. For more than 20 years it existed no harm has 
been noticed. Yes, it is not very wide-spread, but used in some 
circumstances that, I think, are quite weighty argument to make that 
specified (I mean MIL-STD-..., see on the list archive).

And as for my drafts. I would ask to withdraw my draft related to IRTP, 
but make another one suggesting moving it to Historic. As for RDP, I 
suppose draft-ietf-tsvwg-iana-ports authors will kindly allow this (and 
NETBLT) protocol ports to be registered using the unique procedure and 
as soon as this issues will be covered by this draft, I will ask my 
draft to be marked as replaced by iana-ports one. And as for NETBLT 
draft, it will be replaced by new version of White's draft, for which, I 
think, he would allow me to be the co-author.

And lastly, now I ask the authors of draft-ietf-tsvwg-iana-ports to 
address to draft-yevstifeyev-eudp in the way they do it for UDP-Lite to 
allow this protocol ports to be assigned in the same way with UDP-Lite. 
This draft is already in RFC Ed. Queue (currently in the ISR state), but 
if the authors mind this, I will ask it to be the AD-Sponsored one.

All the best,
Mykyta Yevstifeyev

03.01.2011 20:28, Bob Braden wrote:
> Indeed. Netblt was developed purely as an experiment by Dave Clark, 
> who has never encouraged its propagation outside the ivory towers of 
> used, it would have made a DDoS attack on the entire Internet (at 
> least as the Internet existed at that time).  My advice is, leave the 
> Genie in the bottle!  Better to spend your time bringing T/TCP back 
> from the dead ;-))
>
> Bob Braden
>
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Jan 2011 16:57:52 +0100

> on including corresponding entries in the document.

You also received from Joe Touch comments (in private) that it doesn't
look appropriate to include any of these protocols in
draft-ietf-tsvwg-iana-ports because they don't meet the criteria for
being suitable.

You also got the message that you shouldn't create registries unless
they where clearly needed. You never responded to why these protocols
needs registries. It appears to be an action in completeness that seems
inappropriate.

If you have a situation where not creating the registries would create
an interoperability mess than explain that situation.

> think, he would allow me to be the co-author.

As I agree with Joe, having the service name and ports registry define
the RDP registry does not seem to be appropriate. If there is need for a
registry for this, then do it in an individual draft. But please show
why it is appropriate.

> if the authors mind this, I will ask it to be the AD-Sponsored one.

First, I would like to point out that IP protocol numbers are under the
registration rules of Standards Action or IESG approval.
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Thus, just the RFC-editor publication are not going to get the protocol
a IP protocol number. Going that road requires you to get IESG to
approve the allocation.

And I see giving EUDP a protocol number would be the wrong thing to do.
As EUDP is UDP with an twist of having some option fields there is
little gain with this approach and a lot of loss of functionality. You
loose all the NAT and Firewall traversal capability UDP's IP protocol
number gives you. At the same time you also do not address any of the
issues that you create by adding the options. For example security or
congestion control.

If you want to use this it would be many times smarter to sell it as a
standardize shim on top of UDP. Use regular UDP, after that you add a
Service Code field followed by the data offset field. The serivice code
(or secondary destiantion port) indicate the intended service at the
receiver. Then you register one UDP port. That way you can provide the
functionality without consuming any really valuable resources.

So my opinion is that EUDP should not be published in its current form,
either on the standards track or by the RFC-editor as an independent
submission.

I think it is great that you want to contribute, but I think you should
listen to the feedback that is provided and find something that is more
useful for the community, or a way to resolve the comments that you do
receive.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 11 Jan 2011 18:18:19 +0200

Magnus,

Please find some comments below:

> needs registries. It appears to be an action in completeness that seems
Currently I have refused my idea to create some registries for that 
protocols.  My most current view is: IRTP - to Historic; NETBLT - 
respecify; RDP - do nothing.
> registry for this, then do it in an individual draft. But please show
Why is that appropriate?  That is simple - how should RDP ports be 
assigned?  And there is a draft on this topic:

https://datatracker.ietf.org/doc/draft-yevstifeyev-rdp-ports-registry/

but it just augments the ietf-tsvwg-iana-ports 's action on RDP.
> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
In this way the IESG approval is suitable.
> a IP protocol number. Going that road requires you to get IESG to
The RFC Ed. Indep. Subm. are reviewed by IESG.
> number gives you.
I have asked that before, but why do you think that everything with 
unknown IP protocol numbers will be just discarded by midle-boxes?
>   At the same time you also do not address any of the
That seems like an interesting idea for me so I'll think about this and 
answer later.

All the best,
Mykyta Yevstifeyev

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Jan 2011 17:58:00 +0100

> assigned?  And there is a draft on this topic:

But, why does they need to be assigned. If this is an old protocol and
in some limited use. What application(s) do you have that requires
registered ports, rather than dynamically or resolved port numbers?

> unknown IP protocol numbers will be just discarded by midle-boxes?

At least NATs will break your protocol. There are two major issues, on
top of the question if they forward unknown protocol numbers at all.
First the address translation breaks the checksum, and the checksum
would need to be updated to reflect the address translation. Secondly,
if an unknown protocol is translated, it can't be port translated, only
address translated which is will in turn fail if more than two NAT
internal hosts uses this protocol at the same time.

cheers

Magnus Westerlund