gmane.ietf.dhc

IETF-87 (Berlin) Call for Agenda Items

Bernie Volz (volz — 2013-05-23T20:25:36

Hi:



While perhaps a bit early, we are starting the call for agenda items for the dhc wg meeting. And, as late June and July tend to be a prime vacation periods, perhaps best to get people to start thinking about this now.



We have asked for two slots:

-          One 2 ½ hour slot for the usual dhc wg meeting

-          One 1 hour slot as a joint meeting with the sunset4 wg to discuss http://tools.ietf.org/html/draft-perreault-sunset4-noipv4



If you have a draft you would like to discuss, please send your request for agenda time to the dhc chairs. Please include:

-          the title and file name of the draft

-          a brief summary of why it needs to be discussed

-          the speakers name (and email)

-          and how much time you need will need for presentation and anticipated discussion.



We will give priority, if needed, to requests for documents that are currently working group items or were actively discussed on the mailing list.



We do expect to spend some time discussing a r

Re: Question about RFC5908

Ted Lemon — 2013-05-22T20:24:03

Right now no non-time source suboptions are defined.   I don't know what the authors had in mind for this, TBH, but I'm pretty sure that the intent of the text that you see there was to allow for multiple suboptions, as long as only one was a time source option.

If you want to open a can of worms here, the fact is that this option specification is badly broken, not only because it is the only option definition for IPv6 that uses suboptions, but as written, there is no value to the suboptions.   The reason it's broken in this way is that the NTP working group disregarded substantial comment from the DHC working group.

Personally, I think (ad hat off) that the DHC working group should just define a new NTP option and deprecate this one.   There is no excuse for something as basic as configuring an NTP server to be so complicated.

Re: Question about RFC5908

Bernie Volz (volz — 2013-05-22T20:04:04

   This option serves as a container for server location information
   related to one NTP server or Simple Network Time Protocol (SNTP)
   [RFC4330] server.  This option can appear multiple times in a DHCPv6
   message.  Each instance of this option is to be considered by the NTP
   client or SNTP client as a server to include in its configuration.

   The option itself does not contain any value.  Instead, it contains
   one or several suboptions that carry NTP server or SNTP server
   location.  This option MUST include one, and only one, time source
   suboption.  The currently defined time source suboptions are
   NTP_OPTION_SRV_ADDR, NTP_OPTION_SRV_MC_ADDR, and NTP_OPTION_SRV_FQDN.

Those 3 suboptions are the only ones currently defined.

Bottom line is:
- There may be multiple instances of the OPTION_NTP_SERVER option.
- A OPTION_NTP_SERVER ONLY contains suboption(s). (This is what is meant by "The option itself does not contain any value. ")
- Each OPTION_NTP_SERVER MUST only contain ONE time-source

Re: Question about RFC5908

Andre Kostur — 2013-05-22T19:37:13

What other suboptions can it be?

--
Andre Kostur

Re: Question about RFC5908

Ted Lemon — 2013-05-22T18:19:35

It might have been better to say "one or more," but the meaning of the sentence is correct, and your proposed change would make it incorrect.   The option can contain any number of suboptions greater than zero.   Exactly one of those suboptions can be a time source suboption.   That's what the text says, and that's what the text was intended to say.   There is no error or ambiguity here.

Re: Question about RFC5908

Andre Kostur — 2013-05-22T17:52:12

So it's trying to acknowledge that there may be a bunch of other,
unrelated suboptions stuck into this option?   Wait... are we possibly
arguing over a typo?  If we re-read the problematic statement as
"Instead, it contains one _of_ several suboptions that carry..." that
seems to make more sense.

--
Andre Kostur

Re: Question about RFC5908

Ted Lemon — 2013-05-22T17:45:09

No, it doesn't, because not all suboptions are time source suboptions.

Re: Question about RFC5908

Andre Kostur — 2013-05-22T17:38:39

I'm not clear where the RFC forbids a response with two instances of
56, each with one instance of sub-option 1, or where one instance of
56 may only contain one sub-option instance.

I do see where there may be multiple instances of 56 (both sections 4
& 5 acknowledge this), and an instance of 56 may contain multiple
sub-options (section 4, and the diagram of option 56 acknowledge
this).  I do think that the phrasing of "This option MUST include one,
and only one, time source suboption." is ambiguous and does appear to
directly contradict the previous statement "Instead, it contains one
or several suboptions that carry...".





--
Andre Kostur

Re: Question about RFC5908

Bernie Volz (volz — 2013-05-22T17:36:53

I am not in favor of it being filed. The text could certainly have been better but I think it has not been an issue.

- Bernie (from iPad)

On May 22, 2013, at 1:25 PM, "Ted Lemon" <Ted.Lemon< at >nominum.com> wrote:

Re: Question about RFC5908

Ted Lemon — 2013-05-22T17:25:21

An erratum, some errata.   But please don't, because you are mistaken about this (or at least, you have failed to explain why you are not mistaken).

Re: Question about RFC5908

Ted Lemon — 2013-05-22T16:41:16

No, this would be less correct, because you are now allowing for two time source options of the same type, which the current document (I believe correctly) forbids.

Re: Question about RFC5908

Bernie Volz (volz — 2013-05-22T15:30:59

You can always file an errata.

- Bernie

On May 22, 2013, at 9:58 AM, "François-Xavier Le Bail" <fx.lebail< at >yahoo.com> wrote:

Re: Question about RFC5908

François-Xavier Le Bail — 2013-05-22T13:58:24

----- Original Message -----


I think the text is not clear:
Why not :
This option MUST include one, and only one, time source suboption type ?

Re: Conclusion for draft-ietf-dhc-v4configuration-00

Branimir Rajtar — 2013-05-22T08:50:54

Hi,

My comments are inline...

Branimir

From: gnocuil< at >gmail.com [mailto:gnocuil< at >gmail.com] On Behalf Of Cong Liu
Sent: Monday, May 20, 2013 11:55 AM
To: Branimir Rajtar
Cc: dhcwg< at >ietf.org
Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00

Hi Branimir,

In section 1.5 and 3.3.2, should "separation of DHCPv4 and DHCPv4 provisioning" be "separation of DHCPv4 and DHCPv6 provisioning"?

[BR] You're right, it's a typo - I'll fix it for the next version.

I'm confused with requirement no. 4. Does it mean separated DHCPv4/DHCPv6 server devices, or separated IPv4/IPv6 address provisioning process, or separated IPv4 address/other options provisioning process?

[BR] It actually means all of them :) We wanted the solution to be as flexible as possible for the operator so it can be deployed in whatever scenario the operator wishes. I will expand this requirement in the next version of the draft.

Best Regards,
Cong

==============================================
Cong Liu
Tsinghua University

2013/5

Re: Conclusion for draft-ietf-dhc-v4configuration-00

Branimir Rajtar — 2013-05-22T08:45:33

Hi,

I think this is actually already covered - the draft says about keeping IPv4 and IPv6 domains separate and I would say that a lot of significance is put on that. However, looking at the your comment and other comments from the working group, I think I should expand on it and put some more explanations in the next version.

BR,
Branimir

-----Original Message-----
From: Qi Sun [mailto:sunqi.csnet.thu< at >gmail.com] 
Sent: Sunday, May 19, 2013 5:31 AM
To: Branimir Rajtar
Cc: Ted Lemon; dhcwg< at >ietf.org WG; Bernie Volz (volz)
Subject: Re: [dhcwg] Conclusion for draft-ietf-dhc-v4configuration-00

I notice in DHCPv6 based provisioning, it doesn't mention the DHCPv6 server is required to manage IPv4 address while a DHCPv6 client is responsible to configure IPv4 stack. These changes would live with DHCPv6 if one used this set of mechanisms. DHCPv4oSW also has the same issue (IPv4 address & port set are provisioning in DHCPv6 option), while DHCPv4oDHCPv6 doesn't for it's the DHCPv4 client that takes the job.

Is it n

Re: Question about RFC5908

Ted Lemon — 2013-05-21T15:18:11

Yes.   The point is that the option can only contain one suboption in the set (server-addr, multicast-addr, server-fqdn).   There can be more than one of these options, and so there can be more than one source suboption in the DHCPv6 packet: one for each such option.

Question about RFC5908

François-Xavier Le Bail — 2013-05-21T07:44:27

[Adding dhcwg and RFC authors]


Hello,

About RFC5908, "Network Time Protocol (NTP) Server Option for DHCPv6".

Section 4 says: 
The option itself does not contain any value.  Instead, it contains
one or several suboptions that carry NTP server or SNTP server
location.  This option MUST include one, and only one, time source
suboption. 

(http://tools.ietf.org/html/rfc5908#section-4)

It seems to me contradictory:
- The option itself [...]. Instead, it contains one or several suboptions [...]
- This option MUST include one, and only one, time source suboption.

Did I miss something ?

Best regards,

Francois-Xavier le Bail

Re: Conclusion for draft-ietf-dhc-v4configuration-00

Cong Liu — 2013-05-20T09:54:48

Hi Branimir,

In section 1.5 and 3.3.2, should "separation of DHCPv4 and DHCPv4
provisioning" be "separation of DHCPv4 and DHCPv6 provisioning"?

I'm confused with requirement no. 4. Does it mean separated DHCPv4/DHCPv6
server devices, or separated IPv4/IPv6 address provisioning process, or
separated IPv4 address/other options provisioning process?

Best Regards,
Cong


==============================================
Cong Liu
Tsinghua University


2013/5/15 Branimir Rajtar <Branimir.Rajtar< at >t.ht.hr>

_______________________________________________
dhcwg mailing list
dhcwg< at >ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Re: Conclusion for draft-ietf-dhc-v4configuration-00

Ted Lemon — 2013-05-19T16:31:27

I think that would make sense, yes.

Re: Conclusion for draft-ietf-dhc-v4configuration-00

Ted Lemon — 2013-05-19T16:31:10

The problem with the first way is that it means that every DHCPv4-over-DHCPv6 gateway will always try to acquire an IPv4 configuration, even if the CPE network has no IPv4-only devices on it, and accesses no IPv4-only services.   So there will be no way to shut off IPv4 service for CPE networks that don't require it.

On the other hand, as you say, to make the client acquire IPv4 connectivity only when a CPE device tries to use it is more complicated, and may even be impossible to do correctly.

I do not have an easy answer to this question.

Re: Conclusion for draft-ietf-dhc-v4configuration-00

Qi Sun — 2013-05-19T16:17:19

Dear all,


Yes. I think this is what the unknown message draft (draft-ietf-dhc-dhcpv6-unknown-msg-00) documents, which intends to update RFC3315. 

BTW, should we include draft-ietf-dhc-dhcpv6-unknown-msg-00 as a reference in the DHCPv4-over-DHCPv6 draft?

Best Regards,
Qi