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

["Bernie Volz \(volz\)" <[e-mail]>]

Hi Bert:

I'm in agreement with what you state and will make the change in the
next revision (and assuming others don't express a significant
objection).

Thanks.

- Bernie 

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[e-mail]] 
> Sent: Sunday, January 22, 2006 11:08 AM
> To: Bernie Volz (volz); Wijnen, Bert (Bert); [e-mail]; 
> [e-mail]
> Subject: RE: IESG Discusses/Comments on 
> draft-ietf-dhc-dhcpv6-subid-00.txt
> 
> 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