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

Bert:

Great that we can put several issues to rest with minor changes. But
will wait a bit to see if others have comments (either for or against
these changes).

> 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?

I view this differently. If a vendor that doesn't implement the
subscriber id claims that they conform to this RFC (if and when an RFC)
because it doesn't have a MUST yet they have not implemented it at all,
I'm sure the market will quickly learn not to purchase equipment from
such an untrustworthy vendor.

The MAY isn't about implementing. It is about whether the Relay Agent
sends it and whether the server uses it!

The draft uses this in two places:

   DHCPv6 relay agents MAY be configured to include a Subscriber-ID
   option in relayed (RELAY-FORW) DHCPv6 messages.  

And:

   The DHCPv6 server, if it is configured to support this option, MAY
   use this information in addition to other relay agent option data,
   other options included in the DHCPv6 client messages, and physical
   network topology information in order to assign IP addresses,
   delegate prefixes, and/or other configuration parameters to the
   client. 

I don't understand why we would change this to MUST. Most relay agents
don't have subscriber ids today and thus could not send this option.

And, just because the option appears in a relayed request, why force the
server to use it?

This just doesn't make any sense.

Perhaps we should change "MAY" to may and not use RFC 2119 terminology?

- Bernie

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Friday, January 20, 2006 3:03 PM
> To: Bernie Volz (volz); iesg@ietf.org; dhcwg@ietf.org
> Subject: 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