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:bwijnen lucent.com]
> Sent: Sunday, January 22, 2006 11:08 AM
> To: Bernie Volz (volz); Wijnen, Bert (Bert); iesgietf.org;
> dhcwgietf.org
> 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:volzcisco.com]
> > Sent: Friday, January 20, 2006 21:26
> > To: Wijnen, Bert (Bert); iesgietf.org;
dhcwgietf.org
> > 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:bwijnenlucent.com]
> > > Sent: Friday, January 20, 2006 3:03 PM
> > > To: Bernie Volz (volz); iesgietf.org;
dhcwgietf.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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
|