Subject: new issue tracking for ZEROCONF WG

From: Erik Guttman <[email-masked]>
Date: Thu, 06 Feb 2003 20:42:25 +0100

I have transferred our existing issues into a tracking
system based on the one used for the AAA WG.  This will
simplify our ability to keep focus on a single issue at
a time and come to closure on it.

Please see:  http://www.spybeam.org/issues.html

Is anything missing?  Is anything misrepresented?

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

Please submit new issues using the following template:

Description of issue: (short single line description of issue)
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Lengthy description of problem

Or, if you want to be a pal, submit them in html using the
template at http://www.spybeam.org/issue-template.html

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

I will start discussions to try to close some of these issues
tomorrow.

Best regards,

Erik Guttman
ZEROCONF wg cochair

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Feb 2003 01:28:29 +0200

> Is anything missing?  Is anything misrepresented?

I propose to add the following issue.

Section 2.6, paragraph 4 reads:

   If the destination address is a unicast address outside the
   169.254/16 prefix, then the host SHOULD use an appropriate routable
   source address, if it has one. If the host does not have a routable
   source address, then it MAY choose to ARP for the destination address
   and then send its packet, with a link-local source IP address and a
   routable destination IP address, directly to its destination on the
   same physical link. The host MUST NOT send the packet to any router
   for forwarding.

Problem: If the peer is not v4LL-compliant, it will not have an on-link
route for the 169.254/16 prefix. Hence, if a v4LL node chooses to use
its LL address as source address when sending packets to a non-compliant
peer, response packets from the peer are likely be directed to the
default router.

Suggest rewording:

   If the destination address is a unicast address outside the
   169.254/16 prefix, then the host MUST use an appropriate routable
   source address.

MikaL

---

From: Erik Guttman <[email-masked]>
Date: Fri, 07 Feb 2003 11:53:40 +0100

Mika,

I have entered this as issue LL19, see http://www.spybeam.org/ll19.html
Please review it.  It would help if you supplied the issue in the form
of the template, as I had to guess the priority and some other fields.

Thanks,

Erik

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Feb 2003 19:14:39 +0700

Date:        Thu, 06 Feb 2003 20:42:25 +0100
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | I have transferred our existing issues into a tracking
  | system based on the one used for the AAA WG.  This will
  | simplify our ability to keep focus on a single issue at
  | a time and come to closure on it.
  | 
  | Please see:  http://www.spybeam.org/issues.html
  | 
  | Is anything missing?  Is anything misrepresented?

Missing, perhaps in a different sense than you meant there.   Sometimes
there are multiple suggestions for changes, your pages only ever list one.
While just being able to say yes/no to one specific change is an attractive
way to move forward quickly, it can also make it very hard to achieve a
good result, when the best outcome is perhaps neither to accept or reject
a suggested change, but to do something different entirely.

For example, to take one of the (currently) less contentious issues.
LL3: TTL=255 on send, check on receive?

  [Aside: what you have Thomas Narten saying there doesn't look to be even
   slightly related to the issue - looks to be a cut/paste or include wrong
   file error of some kind].

The suggested resolution there is almost a do nothing (just soften the
wording a little)

Others have suggested requiring TTL=1 on send (that isn't mentioned at all).

My suggestion is (was) to simply rip out all mention of TTL's from the LL
draft completely (with the possible exception of a note documenting what
the current implementations do, so future implementors can know with what
they're dealing).

This message isn't intended as an attempt to debate those - rather to
ask what is the preferred method of dealing with this?

You could just add multiple possible resolutions (LL3a LL3b ...) to the
page, then they could be discussed, ones that find no favour marked "dead"
and eventually (we hope) there would be one left.   In this case, one
possible resolution should be added to all issues, which would be "change
nothing".

Or, we could just make every new suggested resolution a new issue, so we'd
end up (in this case) with at least 3 issues related to setting the TTL
on sending, with interdependencies, in that only one can possibly be
accepted.   In that case, the issues page would need links between the
related issues I think.

If these (multiple possible resolutions) should be treated as new issues,
then I'll send some new ones in...   On the other hand, if adding multiple
possible resolutions to the issues is better (I think I prefer that one if
it is possible easily - it makes comparing the various proposals easier)
then please indicate how extra/different resolution suggestions should be
sent.

kre

---

From: Erik Guttman <[email-masked]>
Date: Fri, 7 Feb 2003 15:05:53 +0100 (CET)

Robert,

> there are multiple suggestions for changes, your pages only ever list one.

We must present all offered alternatives so we can pick one.

> a suggested change, but to do something different entirely.

Well that is why we are going to *discuss* each issue not just rotate
thumbs.

>    file error of some kind].

Thanks for pointing this out.  I will find the proper point to cite for
this issue, when Thomas launched this discussion on the list.

> Others have suggested requiring TTL=1 on send (that isn't mentioned at all).

I suggest you file a new issue or suggest some replacement text in this
case.  I am making every effort to be fair, inclusive and represent
all the views in the WG.
 
> possible resolution should be added to all issues, which would be "change

I agree. 

> then please indicate how extra/different resolution suggestions should be

I agree with you.  Let's keep it to one resolution per issue.  The
danger is that we will have issues for which resolutions do not clearly
compete - that the scope of the problems they are solving will not be
coextensive.  If possible, let's *refer to the problem statement* in
another issue and just offer a different resolution.  This will minimize
confusion. 

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n                        
 N1 Installation and Provisioning               cell: +49 172 865 5497 
 Sun Microsystems                     pager: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Feb 2003 23:00:51 +0700

Date:        Fri, 7 Feb 2003 15:05:53 +0100 (CET)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <Pine.SOL.3.96.1030207145534.26222D-100000@field>

  | Thanks for pointing this out.  I will find the proper point to cite for
  | this issue, when Thomas launched this discussion on the list.

When you're fixing that, you might also want to fix the HTML page
titles - all of them claim to be LL1 (this is just more trivia).

  | > Others have suggested requiring TTL=1 on send
  | 
  | I suggest you file a new issue or suggest some replacement text in this
  | case.

That one I will leave to someone who supports that approach (if
there are any left).

  | I am making every effort to be fair, inclusive and represent
  | all the views in the WG.

Please don't misinterpret my message - I was just trying to ask a
question on which method you wanted to use to get this kind of
issue (multiple possible outcomes, of which only one can possibly
be adopted) handled on your web pages.

The TTL case I just picked as an easy (and I hoped, non-inflamatory)
example.

  | I agree with you.

I'm not sure what you're agreeing with, because I was just asking
a question, but ...

  | Let's keep it to one resolution per issue.

Fine, that's an answer that will work.

  | The
  | danger is that we will have issues for which resolutions do not clearly
  | compete - that the scope of the problems they are solving will not be
  | coextensive.

Yes, might happen.

  | If possible, let's *refer to the problem statement* in
  | another issue and just offer a different resolution.  This will minimize
  | confusion. 

OK, will do that.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Feb 2003 19:22:57 +0200

> of the template, as I had to guess the priority and some other fields.

Thanks Erik,

I meant to write the template info but I forgot, sorry about that.
Please update the following fields:

Description of Issue:
		Do not use v4LL source address to non-v4LL destinations

Rationale:	Conversing with non-v4LL nodes using a v4LL source
		address causes response packets to escape the link.

Priority: 	S

The other fields are fine.

Regards,

	MikaL

---

From: John Schnizlein <[email-masked]>
Date: Thu, 27 Feb 2003 12:27:35 -0500

New Issue:

Description of issue: Link-local sources should specify TTL=1
Submitter name: John Schnizlein
Submitter email address: [email-masked]
Date first submitted: 2003-02-27
Comment type: ['T'echnical | 'E'ditorial] T
Priority: ['S' Must fix | '1' Should fix | '2' May fix ] S
Section: 2.7
Rationale/Explanation of issue: Alternative to LL3 and LL21
Proposal:

Replace the current contents of section 2.7 with the following:

   Any host sending an IPv4 packet with a source and/or destination
   address in the 169.254/16 prefix MUST set the TTL in the IP header
   to 1. This includes multicast and broadcast packets with a source
   address in the 169.254/16 prefix."
   
   This requirement enables the normal behavior of Internet routers
   to preclude leaking traffic that is supposed to be confined to a
   single link out into the Internet when the local link has an
   attachment to the Internet that it did not discover. Setting TTL
   to 1 precludes mistaken forwarding of link-local traffic even
   when proxy-ARP is used on a link.

Lengthy description of problem: see discussion of LL3 and LL21