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

["Wijnen, Bert (Bert)" <[e-mail]>]

On a re-read, I think we are more or less in sync.

- So implementation of DHCPv6 server or relay agent
  that claims compliance to this document MUST 
  implement this option.
  This is not stated so clearly, but since it is the 
  only protocol option described in this document 
  it is implied (as I think you are stating in your
  reponse).
- I guess the MAY usage (aka 2119 language) seems
  unwarranted and caused my confusion.
  Making the MAY lowercase and get rid of 2119 language
  I think would be an improvement.

Bert

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]]
> Sent: Friday, January 20, 2006 21:26
> To: Wijnen, Bert (Bert); [e-mail]; [e-mail]
> Subject: 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:[e-mail]] 
> > Sent: Friday, January 20, 2006 3:03 PM
> > To: Bernie Volz (volz); [e-mail]; [e-mail]
> > 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg