[dhcwg] RE: IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-subid-00.txt

W.r.t. to you answer on my DISCUSS:
> ---
> 
> Bert Wijnen:
> 
> Discuss [2005-12-01]:
> Again I wonder how this document (targeted at standards track)
> helps STANDARDIZE anything.
> 
> - the semantic information in the subscriber-ID string is vendor specicic
>   (without even a way to indicate which vendor it is coming from)??
> - a relay agent MAY insert such a subscriebr-ID
> - a server MAY do something or nothing.
> 
> And besides that, to make a subscriber-ID NVT ASCII seems very USA
> centric
> 
> ---
> MY RESPONSE:
> 
> Just as I proposed with 
> draft-ietf-dhc-dhcpv6-remoteid-00.txt, we could
> insert the enterprise-id in the option data and thus the semantic
> information is enterprise specific.

That would be good I think and would addres sthat first concern.

> We could also remove the requirement to make this NVT-ASCII and
> leave it to the enterprise to define.
> However, this requirement was based on the DHCPv4 version (see RFC
> 3993). Perhaps we change the wording to suggest NVT-ASCII, 
> but leave it for the enterprise to decide what is best for
> their needs.
>

Or maybe not "suggest NTV-ASCII", but state that it was/is NVT-ASCII 
in DHCPv4, and so people could choose to do so here too, but allow
UTF-8. In fact I would prescribe UTF8 and make that remark about DHCPv4
and explain that us ASCII in UTF8 is exactly the same and so there
can be compatibility.

> There is no requirement that relay agents insert these options. This is
> the whole idea behind options -- they are, in general, OPTIONAL. If a
> relay agent is configured to insert this and it has the information to
> insert, it will do so. As this option is for use between relay agents
> and servers, these are typically in the same administrative domain and
> thus to be useful, relay agents and servers that support this must be
> purchased if the domain intends to use this capability.
> 

The point is, that with OPTIONAL things, some vendors can choose to
implement and claim compliance. Other may not implement it and can
still claim compliance (they implement all the MUST pieces but
not all theOPTIONAL pieces). And so a customer bying solutions must
go and check every option if it is indeed implemented to have any
hope for interoperability. 

If you make the thing all MUST IMPLEMENT but are OPTIONAL to use,
then interoperabilty becomes much mcuh easier. And isn;t all this
IETF standardization about trying to provide INTEROPERABILITY?

Bert

> ---
> 
> - Bernie
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg