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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 20 Jan 2006 21:02:35 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 Jan 2006 15:26:10 -0500

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).

> 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:[email-masked]] 
> Sent: Friday, January 20, 2006 3:03 PM
> To: Bernie Volz (volz); [email-masked]; [email-masked]
> Subject: RE: IESG Discusses/Comments on 
> draft-ietf-dhc-dhcpv6-subid-00.txt
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 22 Jan 2006 17:07:53 +0100

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

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Friday, January 20, 2006 21:26
> To: Wijnen, Bert (Bert); [email-masked]; [email-masked]

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 22 Jan 2006 14:24:23 -0500

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 

> Sent: Sunday, January 22, 2006 11:08 AM
> To: Bernie Volz (volz); Wijnen, Bert (Bert); [email-masked]; 
> [email-masked]