Subject: [dhcwg] draft-ietf-dhc-fqdn-option to WG last call

From: Ralph Droms <[email-masked]>
Date: Tue, 14 Dec 2004 12:11:00 -0500

There was consensus at the dhc WG meeting in DC to take:

draft-ietf-dhc-fqdn-option-07.txt

to WG last call.  Here are the notes about the discussion of this draft at
the WG meeting:

   Volz presented a status report: these drafts along with
   draft-ietf-dhc-3315id-for-v4 and draft-ietf-dnsext-dhcid-rr will go
   to the IESG as a package.  draft-ietf-dnsext-dhcid-rr is through WG
   last call (dnsext).  The consensus in the room was to go to WG last
   call on draft-ietf-dhc-fqdn-option; consensus will be confirmed on
   the WG mailing list.

If there are no objections posted to the WG mailing list, I will start a WG
last call for this draft on 2004-12-17.

- Ralph 

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 14 Dec 2004 18:04:32 -0500

I just got feedback from Olafur and want to revise the draft to clean up and
improve the language.

Attached is what Olafur sent me.

So, please postpone the WG last call until after the -08 draft is posted and
we receive some feedback on it.

- Bernie

> -----Original Message-----
> From: Ólafur Guðmundsson [mailto:[email-masked]] 
> Sent: Tuesday, December 14, 2004 2:29 PM
> To: Bernie Volz; 'Stapp, Mark'; [email-masked]; 'Olafur Gudmundsson'
> Subject: Re: Updated draft-ietf-dhc-dhc-fqdn-option
> 
> 
> At 14:36 10/12/2004, Bernie Volz wrote:
> >Hi:
> >
> >I've updated the DHCPv4 FQDN draft. New proposed draft and a diff of 
> >the text are attached.
> >
> >Basically, the change was in how the RCODE1/RCODE2 fields were 
> >described -- they are now considered deprecated.
> >
> >Please email me with any other comments that should be 
> addressed before 
> >I re-submit this. I'd like to resubmit by December 17th.
> >
> >- Bernie
> >
> 
> Thanks for the head, up and my apologies for responding this 
> late. Here are my comments:
> 
> 1. The document needs an IANA sections that says the option 
> is already 
> allocated and this document updates the options use, and 
> should be the document that IANA maintains for DHCP Options. 
> There should be an explicit link from section 4 to IANA 
> section and vice versa.
> 
> 2. Document is better than before, and addresses my issue 
> with the RCODE usage.
> 
> 3. The document uses the words "we" as expressing editor 
> opinions, I find this style bad in WG documents. See section 
> 4.1 paragraph 5. (this whole paragraph was real hard to 
> parse, please rewrite).
> 
> 4. The RFC 2119 words are used in lower case in few places,
>          may is used in 27+ places in non upper case
>          must 1
>          required 1
>          should 13
> 
>     please check each one to see if it is an omission of 
> capitalization or
>     if the sentences can be reworded better without the use 
> of the 2119 words.
>          (I found number of these sentences hard to parse)
> 
> 5. Section 3 (applies to some later sections as well)
>          Is the intent to specify that FQDN option can ONLY 
> be sent during
>          lease negotiation ?
>          i.e. client can not send the option after it gets an 
> address to
>          either change the name or add a new name.
>          If the answer is yes then I think that should be 
> stated, if the
>          answer is no then this case needs to be covered.
>          Ralph if you want me to ask the question on the mailing list
>          I will be happy to.
> 
> 6. Can client supply multiple FQDN options ?
>          A client may not like the name assigned by server in OFFER
>          but will take that and use its permanent name also.
>          in this case I would like to see
>          99.30.1.99.in-addr.arpa.        PTR visitor-99.md.ogud.com.
>                                          PTR ralph.dhcp.org.
>                                          PTR ns.dhcp.org.
> 
> 7. Section 4.2 is good except in paragraph 3
> s/it can simply query/is queries/
> 
> 8. Section 4.3 paragraph 1:
> This paragraph contains text inserted during the formative 
> stages of the IDN working group, as the output of that WG did 
> not result in any changes to DNS label types drop everything 
> starting with the word "Eventually".
> 
> Section 4.3 paragraph 2:
> I MUST say this was real confusing reading, please reword.
> I think you want to say client can send PQDN (ie missing 0x00 
> at the end). point to section where server processing of this 
> special case is described.
> 
> 9. Section 4.1 Paragraph 3:
> I think you want to state that FQDN contains an extra label 
> of length 0. (ie ends with 0x00)
> 
> 10. section 5 paragraph 2
> s/Servers will be asked in section 6/Section 6 instructs servers/
> 
> 11. Section 5 meta comment
> I would like to see this section broken into subsections one 
> for each processing rule.
> 
> 
> 12. Section 6 (see comment #11)
> is there one particular time when server SHOULD do DNS 
> update? The answer seems to be buried in paragraphs 5 and 8.
> 
> I found the section to be little bit out of order and not 
> clear to read.
> Suggestion: what does server do if it sees FQDN option or 
> does that depend on when the server gets the option?
> 
> Put DNS processing rules in one (or more subsections)
> Put DHCP rules in clearly defined subsections
>          Request processing rules
>          reply rules
>          DNS update
>          Lease expire rules
> 
> 13: Section 7, last sentence
> This is not area of future work but explicitly linked document.
> 
> 14. security considerations is good.
> 
> In short the document needs at least one more pass after 
> these issues have been addressed.
> 
> Feel free to post this message or any parts of it to the
> dhc mailing list.
> 
>          Olafur

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ralph Droms
> Sent: Tuesday, December 14, 2004 12:11 PM
> To: [email-masked]
> Subject: [dhcwg] draft-ietf-dhc-fqdn-option to WG last call
> 
> 
> to WG last call.  Here are the notes about the discussion of 
> this draft at the WG meeting:
> 
> If there are no objections posted to the WG mailing list, I 
> will start a WG last call for this draft on 2004-12-17.
> 
> 
> - Ralph 
>

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 14 Dec 2004 18:33:38 -0500

>last call for this draft on 2004-12-17.

It is not ready for Last Call, after reviewing the document I sent a long
list of things to fix to the editors (most minor).

Open questions on this document:

Is FQDN option ONLY allowed to be sent by client along with DISCOVER or 
REQUEST?
  Or can client initiate this action at any time ?

Can client include multiple FQDN options if it wants multiple PTR records 
stored
in the reverse tree?

         Olafur

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 15 Dec 2004 10:46:58 -0800

> I just got feedback from Olafur and want to revise the draft to clean up and

So long as you're editing...

After reading this draft I walked away with a feeling that the
client/server interaction between FQDNs and delayed RCODEs (the
special-case 255 values) was poorly defined.

I think there's an implicit behaviour in the draft that every REQUEST
contains an FQDN option.  So in the case where the server sends RCODEs
with 255 values, it is expected to retain the actual RCODEs whenever
they should arrive, and deliver those in the next ACK when the client
reaches its refresh timer and sends a new REQUEST?

That is to say, it all hinges on the "ddns updates made before ACK"
and "ddns updates made after ACK" language, and it's a little fuzzy
that on the next REQUEST you have hopefully completed the DDNS updates
elided from the previous one (rather than simply doing DDNS updates
all over again).

So I'd like to see that made explicit, because it could also be read
that servers choosing to delay DDNS updates will simply always return
255 values, and clients should just deal.

Perhaps both behaviours are acceptable, and it's the discretion of the
implementor?

Along the lines of wondering "How does the client get the real RCODE
when the server delays updates?" I'd had some ideas that may or may
not be worth anything:

1) The server MAY adjust the T1 and/or T2 timers of the offered lease
to exceed its DNS timeout intervals, as a technique of restarting the
DDNS update after a timeout.

2) The server SHOULD NOT transmit DDNS updates more than once without
first receiving another REQUEST from the client (this way, the failing
dns server will not be hindered by updates for clients that have gone
off-net).

3) The server MUST NOT begin DDNS updates in parallel for the same
lease (in the case where DDNS updates are done before ACK this is
implicit).

Should this draft define a behaviour when used in INFORM messages?

> >          99.30.1.99.in-addr.arpa.        PTR visitor-99.md.ogud.com.

Let's not go the multiple option path, this triggers concatenation
behaviour in servers.

I admit to not looking closely enough at the binary encoding of the
option to see if it is identical to that which is used in the
domain-search option (this was not the question I was trying to answer
when I read the draft).  If this is the case, then we may already be
able to  pass multiple names?

If the example included the encoded domain name, I probably would be
more clear on this.

But there is still only one flags field and one pair of RCODE fields.

So as Olafur hints, it should be explicit that the PTR RCODE applies
to all names, and the A RCODE applies to only the first evaluated
name from the encoded field (and any other names are up to the client
to negotiate).  The flags field indicating server updates again only
applies to the first evaluated name.

If the encoding is different, then we'll need yet another flags field
to indicate yet another encoding technique to support multiple names.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 15 Dec 2004 23:43:22 -0500

The RCODE1 and RCODE2 fields are deprecated. The -08 draft will clearly
state this and say that the client SHOULD always set these to 0 and the
server SHOULD set them to 255. So, they will be meaningless. The "SHOULDs"
are there because older servers may return "real" values.

If a client needs to know whether DNS is up-to-date, it can just query the
DNS -- which, after all, is the authoritative source for this information.
Of course, it likely should go after the PTR to find out what name was
actually associated with the address.

---

I don't see much value in using this with INFORM. The DHCP server wouldn't
update the PTR since it didn't assign the address and thus may not have
sufficient authority to update the DNS. And, it is unlikely that the server
could do the A updates for similar reasons?

But, if there is WG interest in this support, it could be added. Though, I'm
really interested in finalizing this work as it has gone on for years. So,
I'd rather we clean up what's there and get it done ... If someone wants to
expand the work, great, but do it later and in a separate draft?

- Bernie

> On Behalf Of David W. Hankins
> Sent: Wednesday, December 15, 2004 1:47 PM
> To: [email-masked]
> Subject: Re: [dhcwg] draft-ietf-dhc-fqdn-option to WG last call
> 
> 
> > I just got feedback from Olafur and want to revise the 
> draft to clean 
> > up and improve the language.
> 
> After reading this draft I walked away with a feeling that 
> the client/server interaction between FQDNs and delayed 
> RCODEs (the special-case 255 values) was poorly defined.
> 
> I think there's an implicit behaviour in the draft that every 
> REQUEST contains an FQDN option.  So in the case where the 
> server sends RCODEs with 255 values, it is expected to retain 
> the actual RCODEs whenever they should arrive, and deliver 
> those in the next ACK when the client reaches its refresh 
> timer and sends a new REQUEST?
> 
> That is to say, it all hinges on the "ddns updates made 
> before ACK" and "ddns updates made after ACK" language, and 
> it's a little fuzzy that on the next REQUEST you have 
> hopefully completed the DDNS updates elided from the previous 
> one (rather than simply doing DDNS updates all over again).
> 
> So I'd like to see that made explicit, because it could also 
> be read that servers choosing to delay DDNS updates will 
> simply always return 255 values, and clients should just deal.
> 
> Perhaps both behaviours are acceptable, and it's the 
> discretion of the implementor?
> 
> 
> Along the lines of wondering "How does the client get the 
> real RCODE when the server delays updates?" I'd had some 
> ideas that may or may not be worth anything:
> 
> 1) The server MAY adjust the T1 and/or T2 timers of the 
> offered lease to exceed its DNS timeout intervals, as a 
> technique of restarting the DDNS update after a timeout.
> 
> 2) The server SHOULD NOT transmit DDNS updates more than once 
> without first receiving another REQUEST from the client (this 
> way, the failing dns server will not be hindered by updates 
> for clients that have gone off-net).
> 
> 3) The server MUST NOT begin DDNS updates in parallel for the 
> same lease (in the case where DDNS updates are done before 
> ACK this is implicit).
> 
> 
> Let's not go the multiple option path, this triggers 
> concatenation behaviour in servers.
> 
> I admit to not looking closely enough at the binary encoding 
> of the option to see if it is identical to that which is used 
> in the domain-search option (this was not the question I was 
> trying to answer when I read the draft).  If this is the 
> case, then we may already be able to  pass multiple names?
> 
> If the example included the encoded domain name, I probably 
> would be more clear on this.
> 
> So as Olafur hints, it should be explicit that the PTR RCODE 
> applies to all names, and the A RCODE applies to only the 
> first evaluated name from the encoded field (and any other 
> names are up to the client to negotiate).  The flags field 
> indicating server updates again only applies to the first 
> evaluated name.
> 
> If the encoding is different, then we'll need yet another 
> flags field to indicate yet another encoding technique to 
> support multiple names.
> 
> --