Re: Edits to draft-ietf-zeroconf-ipv4-linklocal-17.txt

    Date:        Tue, 8 Feb 2005 22:59:39 -0800
    From:        Stuart Cheshire <[email protected]>
    Message-ID:  <[email protected]>

  | 4a. Source and/or destination address
  | 
  |       IPv4 Link-Local addresses SHOULD
  |       only be sent when a Link-Local address is used as the source
  |       address.
  | 
  | should say:
  | 
  |       IPv4 Link-Local addresses SHOULD
  |       only be sent when a Link-Local address is used as the source
  |       and/or destination
  |       address.

I think that one is actually a technical change, but I see no reason
not to make it, except perhaps that it isn't what the WG approved.

  | 4b. The host SHOULD use a routable...
  | 
  |    The host SHOULD use a routable address in preference to an IPv4
  |    Link-Local address except for communication to peers for which the
  |    host has an existing TCP connection at the time in which the host
  |    obtained a routable address configuration.
  | 
  | This says that if a host has *any* existing TCP connection to a peer,

Yes, I guess that it is possible to imagine that someone may be so
stupid as to read the text that way, though I doubt anyone would
actually ever do it.   Correcting that is (just) reasonable, but ...

  |    IPv4 Link-Local address may continue to be used as a source address
  |    in communications where switching to a preferred address would cause
  |    hardship to a specific upper-layer activity (e.g., an existing TCP
  |    connection). For more details, see Section 1.7.

This is not an acceptable replacement.   "cause hardship" ??   What on
earth does that mean - "I'd have to execute an assignment statement,
that's a hardship, so I won't do it".   Let's remain a little more in
keeping with the intent of the text that was agreed.

Replace the 4 lines quoted above with (a spelling checked version of...)

	IPv4 Link-Local address may continue to be used as a source address
	in communications where switching to a preferred address would
	cause communications failure because of the requirements of an
	upper layer protocol (e.g., an existing TCP connection).
	For more details, see Section 1.7.

(to readers of this message, note that that text begins in the middle of
a sentence.)

  | 4c. Set the IPv4 TTL to 1?
  | 
  |    A sensible default for applications which are sending from an IPv4
  |    Link-Local address is to explicitly set the IPv4 TTL to 1.
  | 
  | This would be *REALLY* bad advice to put in the document.

This is definitely a technical change, and totally inappropriate at this
stage.

  | Inexperienced application writers would take this to mean that if they
  | want their application to work with IPv4LL, then they should (to quote
  | the *exact* words of the document) "explicitly set the IPv4 TTL to 1".

Yes, so they can, and provided they note the exact words of the
document "sending from an IPv4 Link-Local address", what they're
doing is just fine.    If they keep the TTL at 1 when sending from
a routable address (to other than a link-local address), that's
simply a bug (one which, incidentally, I cannot imagine surviving
even the most rudimentary of testing by the implementor).

  | I foresee developers making a home networking product, and because they 
  | want it to work with IPv4LL, they will follow the advice of the RFC and 
  | use a setsockopt() call to explicitly set the IPv4 TTL to 1.

I foresee developers doing all kinds of crazy things, but I won't change
the specifications to attempt to handle them all.   People are idiots,
almost all of us, we know that - and we know we do things incorrectly.
Eventually we also fix our mistakes (most times).

  | This text has been removed. The advice to set the TTL to 1 may be 
  | applicable to OS vendors making TCP/IP stacks, but not to application 
  | writers.

Put the text back.   Deleting this was a decision the working group could
have made when the document was under discussion, but there is no longer a
working group to approve any change like this (and I kind of doubt it would
have been approved anyway).


No problems with any of the other changes.   Or perhaps I should say,
given that they're made, they're OK - on the other hand, if someone had
asked *me* to actually make some of the meaningless editorial changes that
have been made, I'd not have been happy at all...

kre