Subject: [renum] Comment on 6renum-static-problem

From: "George, Wes" <[email-masked]>
Date: Fri, 24 Aug 2012 14:21:51 -0400

You may want to include some references to RFC6250 (specifically section 3.2) when discussing the problems around the assumptions of the need or possibility for static addresses. I think some of the language in that document reinforces the idea that the need for static addressing is often based on faulty assumptions about addressing, and would complement the text in this draft nicely.

Also, this draft does a reasonable job at documenting some of the historical reasons for choosing to use static addresses. However, I think that it might be useful for this document to categorize these into use cases that the WG agrees still legitimately require static addressing, as distinct from those where workarounds exist that would enable things that normally use static addressing to move to dynamically-assigned addresses.
For example, the use case about small networks without DNS resources is by no means an unsolvable problem, or even a particularly difficult one to resolve given the relative ease of setting up a DNS server, but I believe that there are examples where the workaround is either unavailable or sufficiently onerous as to not be commonly used. Since this is meant to be a companion to the gap analysis document, identifying those gaps would be helpful, as it would inform future work to resolve some of those issues or make the workarounds easier.

Thanks,

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Aug 2012 07:58:24 +0100

Hi Wes,

On 24/08/2012 19:21, George, Wes wrote:
> You may want to include some references to RFC6250
> (specifically section 3.2) when discussing the problems
> around the assumptions of the need or possibility for static
> addresses. I think some of the language in that document
> reinforces the idea that the need for static addressing is
> often based on faulty assumptions about addressing, and would
> complement the text in this draft nicely.

Yes, and in fact I would reverse the message of 6250 slightly:
*because* some of the "claims" in that section are widely
accepted by application layer programmers, static addresses are
(unfortunately) useful.

> 
> Also, this draft does a reasonable job at documenting some of
> the historical reasons for choosing to use static addresses.
> However, I think that it might be useful for this document to
> categorize these into use cases that the WG agrees still
> legitimately require static addressing, as distinct from
> those where workarounds exist that would enable things that
> normally use static addressing to move to
> dynamically-assigned addresses. 

True, if we can reach consensus ;-)

> For example, the use case
> about small networks without DNS resources is by no means an
> unsolvable problem, or even a particularly difficult one to
> resolve given the relative ease of setting up a DNS server,

That's a hot topic in homenet. Strictly speaking, homenets are
out of scope for 6renum, but small enterprise networks have a
lot in common with large homenets.

> but I believe that there are examples where the workaround is
> either unavailable or sufficiently onerous as to not be
> commonly used. Since this is meant to be a companion to the
> gap analysis document, identifying those gaps would be
> helpful, as it would inform future work to resolve some of
> those issues or make the workarounds easier.

OK, can you be more specific?

Thanks!
   Brian

---

From: "George, Wes" <[email-masked]>
Date: Mon, 27 Aug 2012 10:55:04 -0400

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Saturday, August 25, 2012 2:58 AM
> To: George, Wes
> Cc: [email-masked]; [email-masked]
> Subject: Re: Comment on 6renum-static-problem
>
> > but I believe that there are examples where the workaround is either
> > unavailable or sufficiently onerous as to not be commonly used. Since
> > this is meant to be a companion to the gap analysis document,
> > identifying those gaps would be helpful, as it would inform future
> > work to resolve some of those issues or make the workarounds easier.
>

[WEG] not at the moment. I tried both when originally composing this message and when replying just now to think of a specific example of this, and I'm coming up emptyhanded.

To me that means one of two things - there are few (if any) legitimate uses for static addresses other than to compensate for legacy systems that make bad assumptions or otherwise are hard to fix -OR- we need better input from people more familiar with this problem than me.
If it's the former, that would certainly affect the tone and conclusion of the document. If it's the latter, I'm hoping this will incite some discussion, otherwise we may need to start asking in some places more likely to have significant operator presence (*NOGs, etc). sorry I couldn't be more helpful than that, I'll keep thinking about it...

Wes George