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:53:25 -0500

I don't believe so, but there is the IETF RFC Errata process that could
be used.

- Bernie 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 8:28 PM
To: Bernie Volz (volz); [email-masked]
Subject: RE: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request
Renew and Reply?

Hello Mr. Bernie Volz,

Thank you for your reply.
Your statement is much better than mine.
I could get the correct understanding regarding Secton 5.

Are there any update plan for RFC3646?

Best regards,
> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Thursday, November 02, 2006 8:18 AM
> To: Enokihara, Hideshi ([email-masked]); 
> [email-masked]
> Subject: RE: [dhcwg] [DHCPv6] Can DNS options appear in 
> Solicit, Request Renew and Reply?
> 
> 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.
> 
>    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,
> --
> *************************************
> Hideshi Enokihara
> IPv6 Business
> Network & Software Development Dept.
> Yokogawa Electric Corporation
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

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

Hi,

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

Are the following statements acceptable for you?
------------------------
5.  Appearance of these options

   The DNS Recursive Name Server Option SHOULD only appear in
   the following messages: Advertise and Reply.

   The DNS Recursive Name Server Option number SHOULD only appear
   in the Option Request Option of the following messages:
   Solicit, Request, Renew, Rebind, Information-Request and
   Reconfigure.

   The Domain Search List Option SHOULD only appear in the
   following messages: Advertise and Reply.

   The Domain Search list Option number SHOULD only appear in the
   Option Request Option of the following messages: Solicit,
   Request, Renew, Rebind, Information-Request, and
   Reconfigure.

Best regards, 

> Sent: Thursday, November 02, 2006 10:53 PM
> I don't believe so, but there is the IETF RFC Errata process 
> that could be used.
> 
> - Bernie 
> 
> > Subject: RE: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, 
> > Request Renew and Reply?
> > 
> > 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:
> > - Reconfigure, if I remember correctly, doesn't send the changed 
> > options; just the ORO with the option numbers.
> > 
> > ------------------------
> > 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,
> > ---------------------
> > Does this sentence mean that really DNS Recursive Name 
> Server option 
> > and Domain Search List option can appear in Solicit, 
> Request, Renew, 
> 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?
> > 
> > Section 5 says that Confirm, Decline and Release messages MUST NOT 
> Domain Search 
> > List option.
> > 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.).
> >

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 09 Nov 2006 20:50:20 +0900

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

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]