Subject: RE: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request Renew and Reply?

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 2 Nov 2006 08:42:12 -0500

Yeah, probably SHOULD is better.

- Bernie 

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 1:36 AM
To: Bernie Volz (volz)
Cc: Hideshi Enokihara; [email-masked]
Subject: Re: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request
Renew and Reply?

Bernie Volz (volz) wrote:
> I think the MUST NOT language is a bit strong -- certainly, I would
> expect clients and servers that receive these options in these MUST
NOT
> messages just to ignore them.
> 
> I think your rewording is the correct interpretation, with a few
edits:
> - Make the statements positive, not negative?
> - Reconfigure, if I remember correctly, doesn't send the changed
> options; just the ORO with the option numbers.
> 
> ------------------------
> 5.  Appearance of these options
> 
>    The DNS Recursive Name Server Option MAY only appear in
>    the following messages: Advertise and Reply.

In normal English language this would be just fine. But I think
perhaps it should be avoided if you use capital MAY and reference
RFC 2119. 2119 says:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
    truly optional.  One vendor may choose to include the item because a
    particular marketplace requires it or because the vendor feels that
    it enhances the product while another vendor may omit the same item.
    An implementation which does not include a particular option MUST be
    prepared to interoperate with another implementation which does
    include the option, though perhaps with reduced functionality. In
the
    same vein an implementation which does include a particular option
    MUST be prepared to interoperate with another implementation which
    does not include the option (except, of course, for the feature the
    option provides.)

Wouldn't say SHOULD be closer to what is intended?

Stig

> 
>    The DNS Recursive Name Server Option number MAY only appear
>    in the Option Request Option of the following messages:
>    Solicit, Request, Renew, Rebind, Information-Request and
>    Reconfigure.
> 
>    The Domain Search List Option MAY only appear in the
>    following messages: Advertise and Reply.
> 
>    The Domain Search list Option number MAY only appear in the
>    Option Request Option of the following messages: Solicit,
>    Request, Renew, Rebind, Information-Request, and
>    Reconfigure.
> 
> --------------------------
> 
> - Bernie
> 
> -----Original Message-----
> From: Hideshi Enokihara [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 3:26 AM
> To: [email-masked]
> Subject: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request
> Renew and Reply?
> 
> Hi all,
> 
> I have some questions regarding RFC3646
> (DNS Configuration options for Dynamic Host
> Configuration Protocol for IPv6 (DHCPv6))
> section 5.
> 
> Section 5 says,
> ---------------------
> 5.  Appearance of these options
> 
>    The DNS Recursive Name Server option MUST NOT appear in any other
>    than the following messages: Solicit, Advertise, Request, Renew,
>    Rebind, Information-Request, and Reply.
> 
>    The Domain Search List option MUST NOT appear in any other than the
>    following messages: Solicit, Advertise, Request, Renew, Rebind,
>    Information-Request, and Reply.
> ---------------------
> Does this sentence mean that really DNS Recursive Name Server option
> and Domain Search List option can appear in Solicit, Request, Renew,
> Rebind
> and Information-Request?
> If these DNS options can appear these messages, how should the server
> which receives a Solicit message with a DNS Recursive Name Server
option
> behave? 
> Does the server send a Advertise message with DNS Recursive Name
Server
> option which includes DNS Server IP address?
> 
> I don't think that this behavior is correct.
> In this case, Option Request Option(DNS Recursive Name Server option)
in
> the Solicit message should be used.
> 
> Is my understanding right?
> 
> One more question, reagrding Confirm, Decline and Release message.
> Section 5 says that Confirm, Decline and Release messages MUST NOT
> include the DNS Recursive Name Server option and/or the Domain Search
> List option.
> I can understand this requirement.
> But, it is doubtful whether Section 5 really wanted to mean such a
> thing(Confirm, Decline and Release messages MUST NOT include the DNS
> Recursive Name Server option and/or the Domain Search List option.).
> 
> I think as follows a true meaning of section 5.
> 
> ------------------------
> 5.  Appearance of these options
> 
>    The DNS Recursive Name Server option MUST NOT appear in any other
>    than the following messages: Advertise, Reply and Reconfigure.
> 
>    The Opiton Request Option(DNS Recursive Name Server option)
>    MUST NOT appear in any other than the following messages: 
>    Solicit, Request, Renew, Rebind and Information-Request.
> 
>    The Domain Search List option MUST NOT appear in any other than the
>    following messages: Solicit, Advertise, Reply and Reconfigure.
> 
>    The Opiton Request Option(Domain Search List option)
>    MUST NOT appear in any other than the following messages: 
>    Solicit, Request, Renew, Rebind and Information-Request.
> 
> --------------------------
> 
> What do you think?
> I'm waiting for your comments.
> 
> Best regards,

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 9 Nov 2006 10:40:23 -0500

It does turn out that this may be overly strict as RFC 3315 does allow a client to suggest values for options.

In 17.1.1, there is:

   The client SHOULD include an Option Request option (see section 22.7)
   to indicate the options the client is interested in receiving.  The
   client MAY additionally include instances of those options that are
   identified in the Option Request option, with data values as hints to
   the server about parameter values the client would like to have
   returned. 

And, in 18.1.1:

   The client MUST include an Option Request option (see section 22.7)
   to indicate the options the client is interested in receiving.  The
   client MAY include options with data values as hints to the server
   about parameter values the client would like to have returned.

(On a side note, it is odd that 17.1.1 has SHOULD and 18.1.1 has MUST for the ORO language.)

- Bernie

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 6:50 AM
To: [email-masked]
Cc: Bernie Volz (volz); [email-masked]; [email-masked]
Subject: Re: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request Renew and Reply?

>>>>> On Mon, 6 Nov 2006 17:57:47 +0900, 
>>>>> <[email-masked]> said:

> I would like to post this to the IETF RFC Errata.

> Are the following statements acceptable for you?
> ------------------------

>    The DNS Recursive Name Server Option SHOULD only appear in

>    The DNS Recursive Name Server Option number SHOULD only appear

>    The Domain Search List Option SHOULD only appear in the

>    The Domain Search list Option number SHOULD only appear in the

I'm afraid this change is beyond the acceptable level as a trivial
erratum.  In my understanding we can only make trivial (usually
editorial) error corrections in the RFC errata, and changing MUST
(NOT) to SHOULD is too substantial to be regarded as trivial.

Regarding SHOULD vs MUST (NOT), I don't have a strong opinion, but
MUST seems to be more suitable.  RFC2119 states:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.

which indicates a reasonable motivation behind not complying with a
SHOULD, but I cannot think of a reason in this particular case.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]