Re: Packet mood

2010-05-06 Thread Joe Touch


Dave CROCKER wrote:
 
 
 On 4/1/2010 11:05 AM, Fred Baker wrote:
 So - does RFC 5841 update RFC 3514, or obsolete it?
 
 
 Probably not.  RFC 3514 is actually a protocol.  RFC 5841 is not.
 
 A protocol needs to specify deterministic behavior by participants at
 both ends of the exchange.  Otherwise there cannot be interoperability.
 
 The new entry defines publishing labels.  That is, its focus is on
 conveying mood rather than worrying about the use of mood.  At the
 least, it might have suggested that a bored packet label should be
 subject to a flood of packets in response, just to make the issuer's day
 more interesting?

This would have been easily avoided had this option been given a more
typical April 1-type kind number, e.g., 258.

I recall getting queries about how to support similar April 1 RFCs,
since the indicator wouldn't fit in the intended field (port number
68000, protocol number 258, etc.).

Simply using that kind of (in)sanity check could have helped avoid these
issues...

Joe



signature.asc
Description: OpenPGP digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Packet mood

2010-04-02 Thread Dave CROCKER



On 4/1/2010 11:05 AM, Fred Baker wrote:

So - does RFC 5841 update RFC 3514, or obsolete it?



Probably not.  RFC 3514 is actually a protocol.  RFC 5841 is not.

A protocol needs to specify deterministic behavior by participants at both ends 
of the exchange.  Otherwise there cannot be interoperability.


The new entry defines publishing labels.  That is, its focus is on conveying 
mood rather than worrying about the use of mood.  At the least, it might have 
suggested that a bored packet label should be subject to a flood of packets in 
response, just to make the issuer's day more interesting?


This perhaps sounds like sour grapes to the fun of the April 1 series.  Let me 
assure you that it is.


Some years back, I submitted an IP-over-email specification and Postel rejected 
it.  He noted that the email service would presumably be operating over IP and 
that having IP at two levels created a potential addressing anomaly that the 
specification needed to resolve.  (Later IP-over-IP tunneling work probably 
proved him wrong, but he was certainly right that it was an issue, absent 
empirical data.)


I protested that for goodness' sake this was an April 1 specification.  He 
responded that specifications need to work...



FWIW, the good news is that the labeling is based on DSM-IV, but the bad news is 
that DSM-IV is designed to aid in completing insurance forms, rather than really 
being tailored for treatment-related guidance in dealing with humans or packets...


Given the insurance orientation, perhaps the real purpose of the labels is for 
bilateral SLAs?


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Packet mood

2010-04-01 Thread Fred Baker
So - does RFC 5841 update RFC 3514, or obsolete it?

http://www.ipinc.net/IPv4.GIF

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Packet mood

2010-04-01 Thread Bob Braden



Fred Baker wrote:

So - does RFC 5841 update RFC 3514, or obsolete it?



Silly question, Fred.  What possible relationship could a TCP option 
have to an IP option?


Bob Braden


http://www.ipinc.net/IPv4.GIF

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Packet mood

2010-04-01 Thread Richard Barnes
I hear they were thinking about making it an IPv6 extension header,  
but they were afraid it would never get deployed that way.


--Richard



On Apr 1, 2010, at 2:47 PM, Bob Braden wrote:




Fred Baker wrote:

So - does RFC 5841 update RFC 3514, or obsolete it?


Silly question, Fred.  What possible relationship could a TCP option  
have to an IP option?


Bob Braden


http://www.ipinc.net/IPv4.GIF
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Packet mood

2010-04-01 Thread Scott Brim
If you don't ack a packet, not only does it get angry, it gets _bigger_
and begins to turn green!

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Packet mood

2010-04-01 Thread Michael Richardson

 Fred == Fred Baker f...@cisco.com writes:
Fred So - does RFC 5841 update RFC 3514, or obsolete it?

I guess all packets to/from .xxx sites need to be marked either :@ 
or :o.




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


Re: Packet mood

2010-04-01 Thread TJ
The TCP-Hulk option?
But that is an RFC for next year ...

Maybe we could work our way through all the superheroes ... the BatMan
option comes with lots of other options and a smaller, brightly-clad helper
option (and money!), SuperMan packets can only be stopped by Kryptonite
Firewalls ...


/TJ

On Thu, Apr 1, 2010 at 15:11, Scott Brim scott.b...@gmail.com wrote:

 If you don't ack a packet, not only does it get angry, it gets _bigger_
 and begins to turn green!

 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf




-- 
/TJ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


RFC 5841 on TCP Option to Denote Packet Mood

2010-04-01 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5841

Title:  TCP Option to Denote Packet 
Mood 
Author: R. Hay, W. Turkal
Status: Informational
Stream: Independent
Date:   1 April 2010
Mailbox:r...@google.com, 
tur...@google.com
Pages:  9
Characters: 15024
Updates/Obsoletes/SeeAlso:   None

URL:http://www.rfc-editor.org/rfc/rfc5841.txt

This document proposes a new TCP option to denote packet mood.  This 
document is not an Internet Standards Track specification; it is published 
for informational purposes.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce