Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

["George, Wes" <[e-mail]>]

> From: Antonio M. Moreiras [mailto:[e-mail]]
>
> On 13/08/13 22:54, Mark ZZZ Smith wrote:
> > ----- Original Message -----
> >> For one of our trainings at NIC.br, [snip]
> >
> > ISPs don't just get a /32, they can get larger if they need it.
> Placing too much value on using a /32 in your examples can strongly
> imply that all IPv6 addressing plans must fit within a /32.
>
> We are the NIR in our country, we are aware of that. But the vast
> majority of our allocations are indeed /32. The BCOP are also aware of
> that, and if we want a experiment where we can follow strictly its
> recommendations, then we need a /32 or something shorter.
>
> > The trouble is that if you are too prescriptive, it then creates
> opportunities for people to be lazy in their learning. They rote learn
> rather than understand, and that means they may not be able to cope with
> the situation is even the slightest bit different.
> >
> > I think teaching people to subnet using a range of bits should be
> taught first, so that they can work with a range allocations. Whether it
> is a /32, a /48 or a /29 then doesn't matter. Then give examples of how
> to apply those techniques to various sized IPv6 prefixes to re-enforce
> the methods.
>
[WEG] +1. I think there's a fine line between trying to avoid confusion and making it too easy to verbatim copy something without understanding it.

> My team have been working with IPv6 trainings for 4 years. We trained
> more than 3000 people, from hundreds of ISPs, in a 36h (1 week) hands on
> course during this time, 32 people in each class. We tried a lot of
> different approaches in these years. I don't want to appear rude, or
> smug. I am just trying to demonstrate that we do have some experience in
> this task, and that we know our specific public. I can't say you are
> wrong. Your suggestions are good. Things can be done the way you are
> proposing. But we would prefer, for now and based on our previous
> experience, to do them the way I described before.
>
> I would like also to stress the point that we are not the only group
> working with IPv6 learning, using prefixes other than 2001:db8::/32 in
> labs and documents.
>
> >> Yes, we could use a
> >> /32 from ULA space, instead of from GLA space. But we think it would
> >> generate confusion.
> >>
> >> I think we are not really talking about impossibilities, but about
> >> options. We are talking about to write documents easier to read, labs
> >> easier to understand.
> >>
> >> In some situations, for teaching, or writing scripts for labs,
> howtos,
> >
> >> books, brochures, etc, it's better, simpler, easier, more precise,
> more
> >> clear, to use a prefix shorter than /32. In some situations we are
> doing
> >> that, and we have seen other groups doing the same.
> >>
[WEG] I think over the course of this discussion, you've built a reasonable case for this with real-world examples to back up your assertions. However, just as teachers like you to show your work when solving a math problem, I strongly suggest that you revise the draft to include this supporting information in order to build the case, else you'll have this conversation every time someone reads the draft and is skeptical that more space is needed. I realize that 3849 is light on justification and you patterned this draft after that document, but few would argue that at least one prefix for documentation is necessary and appropriate. As you've seen, fewer are convinced that additional prefixes or larger prefixes are needed without some background information from those with experience in training and documentation that have observed some real-world problems with the current solution. I can't guarantee that you won't have more "you're doing it wrong" arguments, but at least you're demonstrating that it's not an arbitrary request.

Wes George

Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

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.