On Oct 18, 2010, at 11:22 AM, Ted Lemon wrote:

> On Oct 18, 2010, at 8:06 AM, <mohamed.boucad...@orange-ftgroup.com> 
> <mohamed.boucad...@orange-ftgroup.com> wrote:
>>  In addition to the technical reasons mentioned in previous e-mails, I
> 
> I'm sorry, I must have missed that email.   I saw a lot of talk about how the 
> WG consensus was for the FQDN option, and the IESG ought to respect that, and 
> the DHCwg ought not to have a say in it.   

[Alain]
Ted,

I'm sorry, but you might have missed the fact that the original document was 
last called both in Softwire and DHCwg in February.
It is thus incorrect to say that DHCwg is expected to "have no say in it"
I would also like to point out that a few comments were received, mostly 
supportive.
The draft -01 that was submitted for last call contained both an IP address and 
a name.
See last call announcement: 
http://www.ietf.org/mail-archive/web/softwires/current/msg01176.html

So, please, stop saying that the DHCwg never saw that draft.
[/Alain]

> 
>>  Distinct operational teams are responsible for each of the above
>>  mentioned levels.  A clear separation between the functional
>>  perimeter of each team is a sensitive task for the maintenance of the
>>  services we are running.  In particular, regional teams will require
>>  to introduce new resources (e.g., new CGN devices) to meet an
>>  increase of customer base.  The introduction of these new devices
>>  (addressing, redirection, etc.) is implemented locally.  Having this
>>  regional separation provides flexibility to manage portions of
>>  network operated by dedicated teams.
> 
> Okay, I can dig that.

[Alain]
What Mohamed is pointing at is a key piece of information that was missing so 
far in this discussion.
[/Alain.]



> 
>>  In order to be able to meet this operational constraint, the AFTR
>>  option name is part of our requirements.
> 
> See, this is the disconnect.   Are you trying to suggest that this statement 
> logically follows the previous paragraph's description of your circumstances? 
>   Or was that just a non-sequitur?   Because I don't see any logical 
> connection between these two statements.
> 
> It seems to me that you are saying that the DNS will be under the control of 
> this regional team, and the DHCP server is not.   So the regional team is the 
> only team that can make changes to the DNS.   But since the DHCP server will 
> be looking the name up in the DNS, this is a non-problem.   Whether the DHCP 
> server provides an FQDN or an IP address, the source for the IP address the 
> client eventually uses will _always_ be the DNS.   So the regional team will 
> not have a problem updating that information.
> 
> Furthermore, even if it were the case that the regional team couldn't do what 
> you want, is that any justification for the position you've taken?   I don't 
> think it is, because it's an operational issue specific to your organization. 
>   We can't design protocols to suit your organization.   Obviously we'd like 
> to have the flexibility to address your needs, but as far as I can tell, we 
> *have* that flexibility.   And you haven't given any technical explanation 
> for why we don't.

[Alain]
Ted:
We always complain in IETF that operators left the room, that we need more 
operator guidance.
We cannot say that and at the same time dismiss operator input.

Both Mohamed & Roberta have indicated that their operational model is to use a 
layer of indirection between national engineering and regional engineering.
I'm not aware of any model in DHCP that allows for such an indirection. Thus, 
they apparently have decided, for operational reasons, to use DNS as their level
of indirection. Apparently, for talking to Mohamed off-line, this is current, 
well deployed practice, and not just for Orange/FT, but done by many ISPs.

We cannot ignore it. Operational needs should be as important as technical 
needs.

[/Alain.]












_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to