[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reminder: clarification on tunnel entry-point address in "draft-ietf-v6ops-mech-v2-04.txt"



On Fri, 13 Aug 2004, Alex Conta wrote:
> Pekka Savola wrote:
> 
> > [...] 
> > 
> > The proposition was to add language something like "the implementation
> > MUST verify that a manually the source address, if manually
> > configured, is an address of the node" to section 3.5.
> > [...]
> 
> I am surprised to see here an interpretation of what I suggested (and 
> Erik N. supported), which is not accurate, or correct. 

You didn't provide your explicit suggestion so I had to try to
summarize the best I could the point which seemed to be the root cause
for our debate :).

> Originally, and 
> as a primary importance, I (and Erik N.) referred to the following text 
> in Section 3.5:
> 
>                Source Address:
> 
> 
>                  IPv4 address of outgoing interface of the encapsulator
>                  or an administratively specified address as described
>                  below.
> 
> and suggested replacing it with the following text:
> 
>                Source Address:
> 
>                    IPv4 address of the tunnel entrypoint (encapsulator).
>
[Pekka:]
>> Would be OK, I guess.
> 
> This is confusing. You seem to have changed your mind. Do you agree or 
> not to this change?

I see no major fundamental objection to just making that particular
change (except I'd rather avoid it due to being late in the process).  
Why I wrote it as above was that while I saw no fundamental problem
with that particular change, its usefulness seemed to depend on other
changes which I was having bigger objections towards.  That is, it
didn't seem that this particular change alone would have satisfied all
of us, and that was the reason for my wariness.

> The secondary importance text at the end of Section 3.5, that need 
> changing, and to which I made suggestions, as well as some text in 
> Section 3.6, which turns out at a careful reading to be confusing, can 
> be discussed separately.

If there is no need to make other than minor editorial changes in 
section 3.5/3.6 apart from the quote above, I wouldn't have major 
objections, but I'd still like to get input from the WG.

I just think it's more confusing if it's changed as you propose, if we
assume that the point of the protocol specification is not prevent
misconfiguration (but the implementations could, if they wish).  I
think this is the main point we need to get a feeling about first.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings