Mykyta Yevstifeyev | 2 Jan 2011 10:43
Picon

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

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

Mykyta Yevstifeyev | 2 Jan 2011 11:59
Picon

Re: Draft Review request - EUDP

Hello all,

Now, almost after the month, I am ready to comment some issues we were 
discussing about EUDP (that is 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04). So, please find 
some comments below...

01.12.2010 18:10, David Borman wrote:
> On Dec 1, 2010, at 8:29 AM, Mykyta Yevstifeyev wrote:
>
>> 01.12.2010 13:52, Lars Eggert wrote:
>>> Hi,
>>>
>>> On 2010-12-1, at 13:25, Mykyta Yevstifeyev wrote:
>>>> I have recently made a draft which, IMO, will be interesting
>>>> for the WG. You can find it here:
>>>>
>>>> http://datatracker.ietf.org/doc/draft-yevstifeyev-eudp/?include_text=1
>>>>
>>>> Could you please review it?
>>> This is not a useful proposal. Why? UDP is IP plus ports and a checksum. There is no feature negotiation,
no state machine to be extended, etc. *at the protocol level*.
>> IMO (and this is the main purpose of the EUDP) if some feature concerns any protocol or data which is to be
put into payload of the protocol of some layer, the corresponding option should be put in 'this-layer'
protocol header. Moreover, UDP provides core service while TCP or DCCP provide many features which can be
just not needed. EUDP can provide (or not provide) any features except core ones.
>> It is made to provide the choice of features.
> I read the document, and adding option space to UDP is not interesting if you don't also have at least one
useful option defined at the same time.  There is no motivation to implement this with just the NOP and EOL
options.  In addition, as Lars points out, UDP does not have a state machine.  This means that adding any new
option will require that the option can either be safely ignored, or negotiation needs to be added to the
option itself.  That implies potentially sending UDP packets with just options, and no data.  Or the
applications have to do the option negotiation.
>
> So, yes, if you want to add options to UDP, this would be a way to do it, but first you need to have at least one
useful option to make use of the new mechanism.
David, now I have added a few options that, IMO, would be quite useful 
for possible users. So, they are: Echo request and response (see 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.3.2.3) 
and (maybe the most important) Packet ID and Packet Acknowledgment (see 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.3.2.5). 
These two provide the possibility to request the acknowledgment of 
single, unit packet. For more detailed analysis of this packet ACKs 
mechanism can be found at 
http://tools.ietf.org/html/draft-yevstifeyev-eudp-04#section-2.5 .
>>> (Sure, applications using UDP have these things. But they can *already* put whatever they like into the
payload anyway. There is no need for a common spec.)
>>>
>>> Plus, by using a different IP protocol number, it is pretty much guaranteed that middleboxes will
simply drop this traffic.
>> Why do you think that if there is unknown protocol code the traffic will be dropped? Currently there are
142 IP Protocol umbers and near 10 are really used. Will you prove that other 132 are being dropped?
> Middle boxes that filter traffic tend to first block everything and then only allow through things that
they understand, otherwise if they let through unknown traffic it provides a wide-open door for the
middle box to be circumvented.
I really do not understand why do you think so. What danger could the 
traffic with unknown protocol cause? And if it is e. g. 253 or 254 
(experimentation), middleboxes definitely can't know what protocol is 
used. In this occasion they will ignore that traffic, you think?
> 			-David Borman
>
Waiting for other comments.

All the best,
Mykyta Yevstifeyev
>>> Lars
>>>
>>> PS: Meta comment: You have submitted quite a number of IDs lately
(http://tools.ietf.org/id/yevstifeyev). I really do applaud your enthusiasm. But the vast majority
of your IDs to me appear to be rather pointless. I encourage you to follow some WGs that interest you most
more closely, in order to learn where your contributions would be most useful. I'm being blunt here -
please don't be offended. I don't want you to turn away from the IETF in frustration because your
contributions don't get traction; I want your contributions to matter.
>> Thank you for advice.
>>
>> I hope I have explained everything clearly.
>>
>> All the best,
>> Mykyta Yevstifeyev
>

Gorry Fairhurst | 3 Jan 2011 16:56
Picon
Picon

TSVWG Status Update (Jan 2011)


The email below gives a brief snapshot of the current WG status for Jan
2011.

Please look at what needs to be done.

Do send notes of any corrections to tsvwg-chairs <at> tools.ietf.org.

Gorry   James
(TSVWG Chairs)

==================================================================

RFC Published:

draft-ietf-tsvwg-admitted-realtime-dscp-07 (RFC 5865)
draft-ietf-tsvwg-rsvp-proxy-approaches-09 (RFC 5945)
draft-ietf-tsvwg-rsvp-proxy-proto-11 (RFC 5946)
draft-ietf-tsvwg-rsvp-l3vpn-07 (RFC 6016)
draft-ietf-tsvwg-ecn-tunnel-10 (RFC6040)

---
IDs in RFC Editor Queue:

draft-ietf-tsvwg-emergency-rsvp-15 (MISREF)
Norm. ref to router alert draft (in the INT-area WG)

draft-ietf-tsvwg-port-randomization-09 (Auth-48: Awaiting Shepherd)
James is Shepherd.

draft-ietf-tsvwg-emergency-rsvp (MISREF)
Norm. ref to router alert draft (in the INT-area WG)

draft-ietf-tsvwg-sctp-chunk-flags-02 (RFC-Ed)
    was: draft-tuexen-tsvwg-sctp-chunk-flags.
    TSVWG supported adoption (6 people, concluded 3/6/2010).
    List of reviewers supplied by document editor.
    WGLC ended Sept 6th 2010.
    New revision 7th Sept 2010.
    Proto write-up sent by shepherd 22/9/2010.
    IETF Last Call ended 7/10/2010.
    With RFC-Ed
  Gorry is Shepherd.

draft-ietf-tsvwg-dtls-for-sctp-06
   Proto write-up sent by shepherd
   AUTH-48 (Auth-48: Awaiting E Rescorla)
Gorry is Shepherd.

-------------------------------------------------------------------

IDs in IESG processing:

None.

-------------------------------------------------------------------

WG Drafts with Chairs:

draft-ietf-tsvwg-rsvp-security-groupkeying
     WGLC of previous version completed.
     SECDIR review comments received, and updated as version -05.
     Short WGLC to confirm new text ended August 11th 2010.
     New version 22-10-2010.
     Due: Proto write-up needed by shepherd.
   James is Shepherd.

-------------------------------------------------------------------

WG Drafts:

draft-ietf-tsvwg-sctpsocket
     Expecting WGLC.
     New revision 25 Oct 2010.
     This will require an apps area review in WGLC.
     Due: Please volunteer to review this draft in WGLC.
     Due: WGLC due January 2011.

draft-ietf-tsvwg-sctp-strrst
     Dependency on this for IPFIX document with RFC-Ed.
     Benoit Claise to review for IPFIX
     New revision (-08) 25 Oct 2010.
	Text on race-condition to be updated before WGLC
     Due: Please volunteer to review this draft in WGLC.
     Due: WGLC due January 2011.

draft-ietf-tsvwg-iana-ports
     New revision 25 Oct 2010.
     Please volunteer to review this draft in WGLC.
     This will require a multi-working group LC.
        ADs to advice on which WGs need to be a part of LC.
        AD review received 21/12/2010.
     Due: Please volunteer to review this draft in WGLC.
     Due: WGLC due January 2011.
   Gorry is Shepherd.

draft-ietf-tsvwg-byte-pkt-congest
     New editor added Jul 2010.
     New revision 25 Oct 2010.
     Comments needed before deciding if ready for WGLC.

draft-ietf-tsvwg-sctp-udp-encap
     was: draft-tuexen-sctp-udp-encap
     Lars sent a note as AD agreeing to progress this work.
     Work to be coordinated with DCCP work on encaps.
     Adopted as a work item 21 Sept 2010 (Gorry).
	No WG -00 draft.
     New revision expected.

draft-ietf-tsvwg-natsupp-tsvwg
     was: draft-stewart-natsupp-tsvwg.
     Dependency from BEHAVE WG.
     Adopted as a work item 21 Sept 2010 (Gorry).
	WG -00, 29/11/2010
     New revision expected.

-------------------------------------------------------------------

WG action required:

draft-gont-tsvwg-source-quench-01.txt
      IETF-79 suggested there was interest in this topic.
      Comments to list in 2010 from: Fred Baker, Antonio DeSimone,
	James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others.
      WG needs to assess if the new draft should be a work item.

-------------------------------------------------------------------

The following have received recent discussion at TSVWG meetings or on
the list. Inclusion in the list below does not indicate support for
these specific drafts and other contributions are also warmly welcomed.

draft-stewart-tsvwg-sctp-nonce
      IETF-78 suggested there was interest in this topic.
      Please comment to list.
      Revised draft to be uploaded with new name.
      WG needs to assess if the new draft should be a work item.

  draft-polk-tsvwg-intserv-multiple-tspec
      RSVP directorate to be consulted.
      WG interest in this topic recorded at IETF-78.
      Charter update would be needed to progress this work.
      5 Reviews needed to determine energy/technical direction.
      Author will update -04.
      New revision expected.

  draft-lefaucheur-tsvwg-rsvp-multiple-preemption
      RSVP directorate to be consulted.
	- Reviewers: Bruce Davie (awaiting other reviews)
      WG needs to assess if this topic should be a work item.

  draft-wing-tsvwg-happy-eyeballs-sctp
      Please comment to list.

  draft-tuexen-tsvwg-sctp-multipath
      Please comment to list.

  draft-tuexen-tsvwg-sctp-sack-immediately
      Please comment to list.

  draft-lei-tsvwg-sctp-compr-requirements-profile
      Please comment to list.

  draft-wei-tsvwg-nested-header-compression
      Please comment to list.

  draft-nishida-tsvwg-sctp-failover
      Please comment to list.

  draft-narayanan-tsvwg-rsvp-resource-sharing
      Please comment to list.

  draft-polk-tsvwg-rsvp-app-id-vv-profiles
      Please comment to list.

  draft-nishida-natarajan-sctp-failover
      Please comment to list.

  draft-wei-tsvwg-nested-header-compression
      Please comment to list.

-------------------------------------------------------------------

Related non-WG items:

draft-fairhurst-tsvwg-6man-udpzero
      Draft was adopted by 6man, please discuss on the 6man list.
      This will be LC'ed in TSVWG also.

draft-ietf-dccp-udpencap
      DCCP WG item linked to encaps (WGLC)

draft-narayanan-tsvwg-rsvp-resource-sharing
      Authors will take this draft to CCAMP WG.

  draft-ietf-behave-sctpnat-03.txt
      BEHAVE WG item linked to SCTP encapsulation work.

------------------------------------------------------------------

Other news:

  RSVP Directorate (formed in May 2010)
    - Rules and guidelines to be formulated

  Charter to be updated to indicate procedure for adoption.

------------------------------------------------------------------
------------------------------------------------------------------

Gorry Fairhurst | 3 Jan 2011 17:02
Picon
Picon

Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench)

There was discussion of the draft below on the TSVWG list and at the 
last IETF meeting.

Deprecation of ICMP Source Quench messages
(draft-gont-tsvwg-source-quench)
http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01

We'd welcome feedback to the list on the question below:

    "Does the WG believe this document effectively addresses
    an existing problem, and should this draft form the basis for
    a solution?"

Please email the chairs and/or list if you support this as a work item, 
or have comments on the suitability of this draft as a TSVWG work item.

Best wishes,

Gorry & James
(TSVWG Co-Chairs)

John C Klensin | 2 Jan 2011 19:24

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

Mykyta,

This is very encouraging.  Thanks.

best new year's wishes,
   john

--On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev
<evnikita2 <at> gmail.com> 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
> 
> 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
> 

John White | 3 Jan 2011 14:52

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

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-

On Jan 2, 2011, at 1:24 PM, John C Klensin wrote:

> Mykyta,
> 
> This is very encouraging.  Thanks.
> 
> best new year's wishes,
>   john
> 
> 
> --On Sunday, January 02, 2011 11:43 +0200 Mykyta Yevstifeyev
> <evnikita2 <at> gmail.com> 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
>> 
>> 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
>> 
> 
> 
> 
> 

John C Klensin | 3 Jan 2011 16:49

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


--On Monday, January 03, 2011 08:52 -0500 John White
<jccw <at> jccw.org> 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

Bob Braden | 3 Jan 2011 19:28
Picon
Favicon

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


>>
>> 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.

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

>
> 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
>
>
>

david.black | 3 Jan 2011 20:01

RE: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench)

> We'd welcome feedback to the list on the question below:
> 
>     "Does the WG believe this document effectively addresses
>     an existing problem, and should this draft form the basis for
>     a solution?"
> 
> Please email the chairs and/or list if you support this as a work item,
> or have comments on the suitability of this draft as a TSVWG work item.

The problem is that everyone here "knows" that Source Quench is deprecated in "running code", but that
knowledge is not documented.  We really should document it just in case someone who isn't in the "know"
tries to use Source Quench.  This draft does a reasonable job of that by specifying that Source Quench
SHOULD NOT be sent and SHOULD be ignored on receipt.

Proceeding to answer the questions:

1) There is an existing problem, although not a major one.
2) This draft effectively addresses that problem.
3) I support this draft as a tsvwg work item.

A longer list of surveyed implementations in Appendix A would be a good idea (e.g., Windows and MacOS for starters).

Thanks,
--David

> -----Original Message-----
> From: tsvwg-bounces <at> ietf.org [mailto:tsvwg-bounces <at> ietf.org] On Behalf Of Gorry Fairhurst
> Sent: Monday, January 03, 2011 11:02 AM
> To: tsvwg list; tsvwg-chairs <at> tools.ietf.org
> Subject: Deprecation of ICMP Source Quench messages (draft-gont-tsvwg-source-quench)
> 
> There was discussion of the draft below on the TSVWG list and at the
> last IETF meeting.
> 
> Deprecation of ICMP Source Quench messages
> (draft-gont-tsvwg-source-quench)
> http://tools.ietf.org/html/draft-gont-tsvwg-source-quench-01
> 
> We'd welcome feedback to the list on the question below:
> 
>     "Does the WG believe this document effectively addresses
>     an existing problem, and should this draft form the basis for
>     a solution?"
> 
> Please email the chairs and/or list if you support this as a work item,
> or have comments on the suitability of this draft as a TSVWG work item.
> 
> Best wishes,
> 
> Gorry & James
> (TSVWG Co-Chairs)

Joe Touch | 3 Jan 2011 20:30
Picon
Favicon

Re: Draft Review Request - IRTP IANA Considerations


On 12/30/2010 9:48 PM, Mykyta Yevstifeyev wrote:
> Hello all,
>
> Firstly, happy New Year to all.
>
> Find some comments below.
>
> 28.12.2010 17:41, John C Klesin 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.
 >>
> Nevertheless, if there /is/ a protocol that uses the IANA-assigned
> values, there should be appropriate registries.

That's the key. This (and the other protocols you wrote similar docs 
for, e.g., NETBLT and RDP) don't use IANA-assigned values. They have 
values, but there was not a need for a registry for several reasons, 
including the fact that they were experimental.

At this point, they might be better moved to historic than anything 
else. There's no reason to have IANA track or manage their values.

Joe


Gmane