IANA Action state changed to Waiting on RFC Editor from Waiting on Authors

2012-08-22

12

(System)

IANA Action state changed to Waiting on Authors from In Progress

2012-08-17

12

(System)

IANA Action state changed to In Progress from Waiting on Authors

2012-08-15

12

(System)

IANA Action state changed to Waiting on Authors from In Progress

2012-08-13

12

Amy Vezza

State changed to RFC Ed Queue from Approved-announcement sent

2012-08-10

12

(System)

IANA Action state changed to In Progress

2012-08-10

12

Amy Vezza

State changed to Approved-announcement to be sent from None

2012-08-10

12

Amy Vezza

IESG has approved the document

2012-08-10

12

Amy Vezza

Closed "Approve" ballot

2012-08-10

12

Amy Vezza

Ballot approval text was generated

2012-08-10

12

Amy Vezza

Ballot writeup was changed

2012-08-10

12

Amy Vezza

State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

2012-08-09

12

Robert Sparks

[Ballot comment]Thanks for addressing the majority of the points I raised.

Please consider the one remaining (this is not blocking - if you choose to ...

[Ballot comment]Thanks for addressing the majority of the points I raised.

Please consider the one remaining (this is not blocking - if you choose to do nothing it's up to you):

You added text discussing what the effect on a local cache would be when an interface was removed.Should you say something about what happens if the relative priority of interfaces change? (Or are youperhaps thinking that would be the same as removal of an interface and addition of a new one?)

2012-08-09

12

Robert Sparks

[Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss

2012-08-05

12

Stephen Farrell

[Ballot comment]

Thanks for taking my discuss points into account.

2012-08-05

12

Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss

2012-08-02

12

Teemu Savolainen

New version available: draft-ietf-mif-dns-server-selection-12.txt

2012-08-02

11

Stephen Farrell

[Ballot discuss]

For -11, we just have point 3 left where we agreed a sentence but I don'tsee any change in 4.5 ...

[Ballot discuss]

For -11, we just have point 3 left where we agreed a sentence but I don'tsee any change in 4.5.

(1) cleared

(2) cleared

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.5 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable. (Sentence agreed)

(4) cleared

2012-08-02

11

Stephen Farrell

Ballot comment and discuss text updated for Stephen Farrell

2012-08-01

11

Teemu Savolainen

New version available: draft-ietf-mif-dns-server-selection-11.txt

2012-08-01

10

Stephen Farrell

[Ballot discuss]

In the process of updating these for -10

(1) cleared

(2) What is the lifetime of the domain/network information received in a ...

[Ballot discuss]

In the process of updating these for -10

(1) cleared

(2) What is the lifetime of the domain/network information received in aDHCP response? 4.2 is vague about that, talking about "generalevents." Given that DHCP lease times vary enormously I'd have thoughtyou'd need to be more precise here. (stateful = lease time, statelesswho knows, so implementation specific)

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.5 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable. (Sentence agreed)

(4) cleared

2012-08-01

10

Stephen Farrell

Ballot discuss text updated for Stephen Farrell

2012-08-01

10

Stephen Farrell

[Ballot discuss]

In the process of updating these for -10

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced ...

[Ballot discuss]

In the process of updating these for -10

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced thatimplementations would all do the same thing based on this descriptionand with the same input preferences. Is it required that differentimplementation's behaviour be the same in that case? If not, then lotsof the 2119 language ought to be omitted. If so, then I think you needto re-write it more clearly, e.g. using pseudo-code. (Or convinceme this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in aDHCP response? 4.2 is vague about that, talking about "generalevents." Given that DHCP lease times vary enormously I'd have thoughtyou'd need to be more precise here. (stateful = lease time, statelesswho knows, so implementation specific)

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.5 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable. (Sentence agreed)

(4) cleared

2012-08-01

10

Stephen Farrell

Ballot discuss text updated for Stephen Farrell

2012-07-21

10

Stephen Farrell

[Ballot discuss]

In the process of updating these for -10

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced ...

[Ballot discuss]

In the process of updating these for -10

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced thatimplementations would all do the same thing based on this descriptionand with the same input preferences. Is it required that differentimplementation's behaviour be the same in that case? If not, then lotsof the 2119 language ought to be omitted. If so, then I think you needto re-write it more clearly, e.g. using pseudo-code. (Or convinceme this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in aDHCP response? 4.2 is vague about that, talking about "generalevents." Given that DHCP lease times vary enormously I'd have thoughtyou'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.5 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable.

(4) section 6, 3rd para: is the MUST there expected to be enforced? Ifso how and by whom?

2012-07-21

10

Stephen Farrell

[Ballot comment]I didn't udate these for -10

(This could do with an editorial pass but I'm only going to noteplaces where ...

[Ballot comment]I didn't udate these for -10

(This could do with an editorial pass but I'm only going to noteplaces where a change is more than purely grammatical.)

- Is the title ok? The spec is more about private namespaces but the title reads as something more generic.

- section 1, 4th para: selection of "route"? do you mean interface?(Also is "IP connection" right given UDP is most commonly usedfor DNS?)

- section 1, 4th para: be good to give some refs to the kinds of toolyou mean in the last sentence. (If possible)

- Acronyms like VLAN, WLAN etc. would be better expanded

- 4.1, 2nd para on p10 says "routes" again, which is probably wrong

- 4.1 mentions "medium priority" but that's not been introduced

- 4.1 says you "MUST" take into account trust levels but those aren'tdefined and are left to implementations, so I'm not sure that 2119MUST is usefuln (see dicsuss point 1 as well)

- The encoding of the domains and networks in figure 5 is a bitopaque, the reference to 3315 for example is to a section that is 5lines long and refers to 1035. Would some more descriptive material orexamples help here? I can imagine implementers going wrong here, butperhaps its ok and the people who'd write code for this would befine.

- OPTION_ORO could do with a reference or brief explanation in 4.2for the less DHCP-literate (like me:-)

- I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6providing conflicting RDNSS selection information on the sameinterface, or on the equally trusted interfaces, the node SHALLfirstly prefer DHCP-version possibly securingOPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."

- last para of 4.5, would s/may choose to omit/MAY omit/ be better?

- section 7, 2nd para, that MUST is really a SHOULD isn't it? (Thereare exceptions and its not enforceable.)

2012-07-21

10

Stephen Farrell

Ballot comment and discuss text updated for Stephen Farrell

2012-07-21

10

Stephen Farrell

[Ballot discuss]

In the process of updating these for -09

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced ...

[Ballot discuss]

In the process of updating these for -09

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced thatimplementations would all do the same thing based on this descriptionand with the same input preferences. Is it required that differentimplementation's behaviour be the same in that case? If not, then lotsof the 2119 language ought to be omitted. If so, then I think you needto re-write it more clearly, e.g. using pseudo-code. (Or convinceme this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in aDHCP response? 4.2 is vague about that, talking about "generalevents." Given that DHCP lease times vary enormously I'd have thoughtyou'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.5 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable.

(4) section 6, 3rd para: is the MUST there expected to be enforced? Ifso how and by whom?

2012-07-21

10

Stephen Farrell

Ballot discuss text updated for Stephen Farrell

2012-07-21

10

Stephen Farrell

[Ballot discuss]

In the process of updating these for -09

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced ...

[Ballot discuss]

In the process of updating these for -09

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced thatimplementations would all do the same thing based on this descriptionand with the same input preferences. Is it required that differentimplementation's behaviour be the same in that case? If not, then lotsof the 2119 language ought to be omitted. If so, then I think you needto re-write it more clearly, e.g. using pseudo-code. (Or convinceme this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in aDHCP response? 4.2 is vague about that, talking about "generalevents." Given that DHCP lease times vary enormously I'd have thoughtyou'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.4 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable.

(4) section 6, 3rd para: is the MUST there expected to be enforced? Ifso how and by whom? This is unchanged from -08.

2012-07-21

10

Stephen Farrell

[Ballot comment]I didn't udate these for -09

(This could do with an editorial pass but I'm only going to noteplaces where ...

[Ballot comment]I didn't udate these for -09

(This could do with an editorial pass but I'm only going to noteplaces where a change is more than purely grammatical.)

- Is the title ok? The spec is more about private namespaces but the title reads as something more generic.

- section 1, 4th para: selection of "route"? do you mean interface?(Also is "IP connection" right given UDP is most commonly usedfor DNS?)

- section 1, 4th para: be good to give some refs to the kinds of toolyou mean in the last sentence. (If possible)

- Acronyms like VLAN, WLAN etc. would be better expanded

- 4.1, 2nd para on p10 says "routes" again, which is probably wrong

- 4.1 mentions "medium priority" but that's not been introduced

- 4.1 says you "MUST" take into account trust levels but those aren'tdefined and are left to implementations, so I'm not sure that 2119MUST is usefuln (see dicsuss point 1 as well)

- The encoding of the domains and networks in figure 5 is a bitopaque, the reference to 3315 for example is to a section that is 5lines long and refers to 1035. Would some more descriptive material orexamples help here? I can imagine implementers going wrong here, butperhaps its ok and the people who'd write code for this would befine.

- OPTION_ORO could do with a reference or brief explanation in 4.2for the less DHCP-literate (like me:-)

- I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6providing conflicting RDNSS selection information on the sameinterface, or on the equally trusted interfaces, the node SHALLfirstly prefer DHCP-version possibly securingOPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."

- last para of 4.5, would s/may choose to omit/MAY omit/ be better?

- section 7, 2nd para, that MUST is really a SHOULD isn't it? (Thereare exceptions and its not enforceable.)

2012-07-21

10

Stephen Farrell

Ballot comment and discuss text updated for Stephen Farrell

2012-07-02

10

Sean Turner

[Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss

2012-06-29

10

Brian Haberman

[Ballot comment]Thanks for addressing my DISCUSS points.

2012-06-29

10

Brian Haberman

[Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss

2012-06-29

10

Barry Leiba

[Ballot comment]UPDATE: The -09 version fixes the IANA section and makes Section 4.1 much clearer. I know this took some back-and-forth and ...

[Ballot comment]UPDATE: The -09 version fixes the IANA section and makes Section 4.1 much clearer. I know this took some back-and-forth and some bit of work, so thanks very much for taking the time to do it. I'm also satisfied with the resolution of my non-blocking comments, and thanks for that as well.

Comments saved for posterity...========These were formerly DISCUSS comments, and have since been addressed; thanks.

-- 4.1 -- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

The RDNSSes of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority RDNSSes. The non- exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic.

You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.

-- IANA Considerations --Perhaps this is clear enough for IANA, but I see registries specified without their proper names, so I worry:

1. It looks like the first option code is meant to go into the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".

2. It looks like the second option code is meant to go into the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".

Please either confirm or correct that and put the *exact* names of the registries in (you can look for them in http://www.iana.org/protocols/ ). That avoids problems for IANA later.

========Substantive comments; these are non-blocking, but please consider themseriously, and feel free to chat with me about them:

This comment is short of being a DISCUSS, because the document is generally OK and I think I've understood it. I have great respect for the work of the non-native-English editors; still, there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing. I'd like to see the native-English-speaking co-editor (or some other volunteer) go over the document and make sure the articles, tenses, plurals, and commas are right. There's a lot of fixing needed.

-- 4.1 -- For security reasons the RDNSS selection information MUST be used only when it is safe to do so, see Section 4.4 for details.

This phrasing is easy to misinterpret ("[x] MUST be used"). I suggest casting it more directly: For security reasons the RDNSS selection information MUST NOT be used unless it is safe to do so, see Section 4.4 for details.

-- 4.1 -- Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent.

...and, I presume, the specification of that trust model is out of scope for this document. I suggest you explicitly say that, before you give the (very good) examples: Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent, and the details of determining that trust are beyond the scope of this specification. Trust might, for example, be based on the nature of the interface: an authenticated and encrypted VPN, or a layer 2 connection to a trusted home network, might be considered as trusted, while an unauthenticated and unencrypted connection to an unknown visited network would likely be considered as untrusted. In some situations, an interface might be considered trusted only if it has been explicitly configured to be.

I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you should be cautious in using it casually.

If a DNS response is not proven to be unmolested using DNSSEC, then a node cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect the forgery without DNSSEC.

First, this is a convoluted sentence, with too many negatives; second, you're burying the lede. The important point here is that DNSSEC is necessary, so put it up front: DNSSEC is necessary to detect forged responses, and without it any DNS response could be forged or altered. Unless the DNS responses have been validated with DNSSEC, a node cannot make a decision to prefer data from any interface with any great assurance.

-- Figures 5 and 6 -- Reserved: Field reserved for the future. MUST be set to zero.

It would seem to be useful for those future applications if we made sure that implementations didn't barf on receipt of some future value here. Would this work?: Reserved: Field reserved for the future. MUST be set to zero; MUST be ignored on receipt.

-- Figure 8 --Does this diagram tell me anything useful? If so, I can't figure out what. The only interesting part is in the "black box".

-- 10.2 -- An implementation may not be able to determine trust levels without explicit configuration provided by user or administrator.

OK, if you're going to go there, I have to: do you really think there's any serious possibility of user configuration here, especially in the case of a home-network user? I think that if you mention user configuration, you have to mention that in many, if not most, scenarios, user configuration is not a realistic possibility, and administrator configuration and policy heuristics are usually the only viable mechanisms.

========Other comments; no need to respond to these. Take them or modify themas you please:

"timeout" should be one word, not two (but "timed out" is, correctly, two).

-- 4.1 -- The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes resources such as energy. The amount of wasted energy can be significant, for example when radio interfaces has to be started just for the queries.

Maybe it's just an artifact of where the page break happened, but I wondered what the "energy" thing was until I saw "radio interfaces" (on the next page). I suggest using "power" rather than "energy", and specifically noting battery-powered and constrained environments. Perhaps this: The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes resources such as power (in the case of battery powered and constrained environments). The wasted power can be significant: consider starting multiple radio interfaces just for parallel DNS queries.

2012-06-29

10

Barry Leiba

[Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss

2012-06-29

10

(System)

Sub state has been changed to AD Followup from Revised ID Needed

2012-06-29

10

Teemu Savolainen

New version available: draft-ietf-mif-dns-server-selection-10.txt

2012-06-22

09

Jean Mahoney

Request for Telechat review by GENART is assigned to Christer Holmberg

2012-06-21

09

Cindy Morgan

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation

2012-06-21

09

Benoît Claise

[Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise

2012-06-21

09

Wesley Eddy

[Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy

2012-06-21

09

Sean Turner

[Ballot discuss]1) s4.2 & s4.3: Add that the reserved bits MUST be ignored on receipt.

2) s4.2 & s4.3: Need ...

[Ballot discuss]1) s4.2 & s4.3: Add that the reserved bits MUST be ignored on receipt.

2) s4.2 & s4.3: Need to specify what to do if the prf value 10 is received.

2012-06-21

09

Sean Turner

[Ballot comment]I agree with Robert and Stepehen's discuss positions.

0) s1: Includes the following:

The node ought to be able to ask ...

[Ballot comment]I agree with Robert and Stepehen's discuss positions.

0) s1: Includes the following:

The node ought to be able to ask right RDNSS for the information it needs.

by "right" you mean the RDNSS that holds the data that's been asked for even if it's private. how about:

The node ought to be able to query the RDNSS that can resolve the query regardless of whether the answer comes from the public DNS or a privte namespace.

1) s2.2: r/It is worth noting is that/It is worth noting that

2) s3.1: r/instead CPE should send/instead CPE need only send

3) s3.3: r/should be send/need to be sent r/network may be used./network may be used for all other traffic.

4) s4.1: I tend to agree with Stephen here. I think what you want to say is that the specific procedures here are non-normative but an implementation must end up wit h the same result. Pseudocode would help tremendously. Avoiding using lowercase may, shall, should, and must would also help.

5) s4.1: When you say precedence are you saying that the higher precedence should cause processing of lower precedence ones to be stopped or is this just about picking the next value to process?

6) s4.1: priority or precedence pick one ;)

7) s4.2: r/should be contacted/can be contacted

8) s4.2: r/MAY then/can then

9) s4.2: r/extent/extend

10) s4.2:

OLD:

In the case of conflicting RDNSS address is learned from less trusted interface, the node MUST ignore the option.

NEW:

When a conflicting RDNSS address is learned from less trusted interface, the node MUST ignore the option.

11) s4.4: Agree with Stephen's discuss #3.

2012-06-21

09

Sean Turner

[Ballot Position Update] New position, Discuss, has been recorded for Sean Turner

2012-06-21

09

Adrian Farrel

[Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel

2012-06-21

09

Gonzalo Camarillo

[Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo

2012-06-20

09

Ralph Droms

State changed to IESG Evaluation from Waiting for AD Go-Ahead

2012-06-20

09

Ron Bonica

[Ballot comment]Support Brian's DISCUSS. Please consider rewriting this document. I found it very difficult to parse.

2012-06-20

09

Ron Bonica

[Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica

2012-06-20

09

Robert Sparks

[Ballot discuss]It's not clear from the discussion of the premise in the introduction if the document intends to cover the case of receiving ...

[Ballot discuss]It's not clear from the discussion of the premise in the introduction if the document intends to cover the case of receiving different answers to queries into a public namespace depending on which interface the query was made over. For example, getting different results, per interface, for queries into e164.arpa will lead to calls using different technologies with potentially radically different security properties. This needs to be clarified throughout the document and at least discussed in the security considerations.

Building on Stephen's first discuss point - the algorithm in 4.1 relies on the interfaces having a ordered "trusted" attribute, but the source of that ordering is unspecified. The text recognizes that this is "implementation and/or node deployment dependent". Won't this also typically be application dependent? How is this specification going to help interoperability (or reliably improve the overall performance of individual nodes) without a more consistent definition of how this ordering is obtained? Is it conflating "trust" with "preference"? As Barry notes, additional discussion of what's actually likely to be used for inputs into this ordering is warranted. For example, if an end user disagrees with the typical trust ordering you call out for a cellular interface in scenario 3.2, should he expect to be able to do anything about it?

This sentence is problematic: "The non-exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic." Please rewrite that without the 2119 keyword, and ensure that the actual normative requirement is well specified.

You call out a problem with local DNS caching for hosts with a single interface that moves between networks, but don't discuss the affects of local caches when this solution is used. Should that discussion be added (at least commenting on whether this solution helps)? Would you change anything in the local cache as interfaces come and go? What do you do with cached results when the preference or trust levels of interfaces change?

Can you add guidance for how an administrator should chose the prf settings to be configured. Right now, it's hard to see why they wouldn't always chose "High". If you don't want deployments doing that, please say what they should be doing instead. An example deployment scenario showing the value of having different prf levels would go a long way.

Is there some discussion of the potential for spoofing the RDNSS (by spoofing its source address) when a client is relying on item 4 of section 4.4 somewhere?

2012-06-20

09

Robert Sparks

[Ballot comment]The reader has to make a fairly large leap to understand what "default" and "specific" mean in FIgure 4. Please consider additional introduction ...

[Ballot comment]The reader has to make a fairly large leap to understand what "default" and "specific" mean in FIgure 4. Please consider additional introduction to the figure making what those mean more explicit.

[Ballot Position Update] New position, Discuss, has been recorded for Robert Sparks

2012-06-20

09

Stewart Bryant

[Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant

2012-06-19

09

Stephen Farrell

[Ballot discuss]

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced thatimplementations would all do the same thing ...

[Ballot discuss]

(1) 4.1 has a LOT of 2119 keywords, however, I'm just not convinced thatimplementations would all do the same thing based on this descriptionand with the same input preferences. Is it required that differentimplementation's behaviour be the same in that case? If not, then lotsof the 2119 language ought to be omitted. If so, then I think you needto re-write it more clearly, e.g. using pseudo-code. (Or convinceme this is a dumb DISCUSS point:-)

(2) What is the lifetime of the domain/network information received in aDHCP response? 4.2 is vague about that, talking about "generalevents." Given that DHCP lease times vary enormously I'd have thoughtyou'd need to be more precise here.

(3) I don't see how a piece of DNS or DHCP code can know if the criteriain 4.4 apply, at least as they are stated now. For example, forcriterion 1, how can a piece of code know that a given networkprovides a "secure, trusted channel"? There are cases where you canknow, but they're not called out here in a way that can be implementedit seems. My concern is that implementations will just assume its okand then be vulnerable.

(4) section 7, 3rd para: is the MUST there expected to be enforced? Ifso how and by whom?

2012-06-19

09

Stephen Farrell

[Ballot comment]

(This could do with an editorial pass but I'm only going to noteplaces where a change is more than purely grammatical ...

[Ballot comment]

(This could do with an editorial pass but I'm only going to noteplaces where a change is more than purely grammatical.)

- Is the title ok? The spec is more about private namespaces but the title reads as something more generic.

- section 1, 4th para: selection of "route"? do you mean interface?(Also is "IP connection" right given UDP is most commonly usedfor DNS?)

- section 1, 4th para: be good to give some refs to the kinds of toolyou mean in the last sentence. (If possible)

- Acronyms like VLAN, WLAN etc. would be better expanded

- 4.1, 2nd para on p10 says "routes" again, which is probably wrong

- 4.1 mentions "medium priority" but that's not been introduced

- 4.1 says you "MUST" take into account trust levels but those aren'tdefined and are left to implementations, so I'm not sure that 2119MUST is usefuln (see dicsuss point 1 as well)

- The encoding of the domains and networks in figure 5 is a bitopaque, the reference to 3315 for example is to a section that is 5lines long and refers to 1035. Would some more descriptive material orexamples help here? I can imagine implementers going wrong here, butperhaps its ok and the people who'd write code for this would befine.

- OPTION_ORO could do with a reference or brief explanation in 4.2for the less DHCP-literate (like me:-)

- I can't parse this, from 4.5: "In the case of DHCPv4 and DHCPv6providing conflicting RDNSS selection information on the sameinterface, or on the equally trusted interfaces, the node SHALLfirstly prefer DHCP-version possibly securingOPTION_DNS_SERVER_SELECT, and secondly prefer DHCPv6 over DHCPv4."

- last para of 4.5, would s/may choose to omit/MAY omit/ be better?

- section 7, 2nd para, that MUST is really a SHOULD isn't it? (Thereare exceptions and its not enforceable.)

2012-06-19

09

Stephen Farrell

[Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell

2012-06-18

09

Martin Stiemerling

[Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling

2012-06-15

09

Russ Housley

[Ballot comment]

Please consider the editorial comments from the Gen-ART Review by Christer Holmberg on 5-Jun-2012. The review can be found here ...

[Ballot Position Update] New position, No Objection, has been recorded for Russ Housley

2012-06-15

09

Brian Haberman

[Ballot discuss]1. The start of section 4.1 simply states that resolvers should use DHCP to determine which RDNSSes are capable of resolving specific ...

[Ballot discuss]1. The start of section 4.1 simply states that resolvers should use DHCP to determine which RDNSSes are capable of resolving specific domain names and/or addresses. Given that the mechanism for doing such a query via DHCP is defined in this document, I would suggest that the introductory text in 4.1 give a forward pointer to section 4.2 where the mechanism is actually defined.

2. The DHCP option for determining which RDNSSes are capable of resolving certain names and prefixes seems incomplete. How many names/addresses should/can the server return within a single instance of the option? In what situations would you recommend returning more than one instance of the option, one per RDNSS? Additional guidance for both implementers and operators would be useful.

2012-06-15

09

Brian Haberman

[Ballot comment]1. I support the DISCUSS points raised by Barry and agree that the document needs a complete review by a native English speaking ...

[Ballot comment]1. I support the DISCUSS points raised by Barry and agree that the document needs a complete review by a native English speaking author.

2. The packet layout in Figure 5 puts the option-code name (OPTION_DNS_SERVER_SELECT) in the actual field rather than labeling the field as "option-code".

2012-06-15

09

Brian Haberman

[Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman

2012-06-14

09

Barry Leiba

[Ballot discuss]-- 4.1 -- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

The RDNSSes of ...

[Ballot discuss]-- 4.1 -- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

The RDNSSes of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority RDNSSes. The non- exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic.

You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.

-- IANA Considerations --Perhaps this is clear enough for IANA, but I see registries specified without their proper names, so I worry:

1. It looks like the first option code is meant to go into the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".

2. It looks like the second option code is meant to go into the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".

Please either confirm or correct that and put the *exact* names of the registries in (you can look for them in http://www.iana.org/protocols/ ). That avoids problems for IANA later.

2012-06-14

09

Barry Leiba

Ballot discuss text updated for Barry Leiba

2012-06-14

09

Barry Leiba

[Ballot discuss]-- 4.1 -- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

The RDNSSes of ...

[Ballot discuss]-- 4.1 -- The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted

But two paragraphs earlier, you say this:

The RDNSSes of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority RDNSSes. The non- exhaustive list on figure 4 illustrates how the different trust levels of received RDNSS selection information SHOULD influence the RDNSS selection logic.

You give a reason for violating that MUST NOT, and Figure 4 has two cases where the less trusted RDNSS is prioritized higher than the trusted one.

2012-06-14

09

Barry Leiba

[Ballot comment]Substantive comments; these are non-blocking, but please consider themseriously, and feel free to chat with me about them:

This comment is short ...

[Ballot comment]Substantive comments; these are non-blocking, but please consider themseriously, and feel free to chat with me about them:

This comment is short of being a DISCUSS, because the document is generally OK and I think I've understood it. I have great respect for the work of the non-native-English editors; still, there are some significant bits that are in sufficiently fractured English as to be hard to read and possibly confusing. I'd like to see the native-English-speaking co-editor (or some other volunteer) go over the document and make sure the articles, tenses, plurals, and commas are right. There's a lot of fixing needed.

-- 4.1 -- For security reasons the RDNSS selection information MUST be used only when it is safe to do so, see Section 4.4 for details.

This phrasing is easy to misinterpret ("[x] MUST be used"). I suggest casting it more directly: For security reasons the RDNSS selection information MUST NOT be used unless it is safe to do so, see Section 4.4 for details.

-- 4.1 -- Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent.

...and, I presume, the specification of that trust model is out of scope for this document. I suggest you explicitly say that, before you give the (very good) examples: Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent, and the details of determining that trust are beyond the scope of this specification. Trust might, for example, be based on the nature of the interface: an authenticated and encrypted VPN, or a layer 2 connection to a trusted home network, might be considered as trusted, while an unauthenticated and unencrypted connection to an unknown visited network would likely be considered as untrusted. In some situations, an interface might be considered trusted only if it has been explicitly configured to be.

I remind you that "shall" is a 2119 keyword (synonymous with "must"), and you should be cautious in using it casually.

If a DNS response is not proven to be unmolested using DNSSEC, then a node cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect the forgery without DNSSEC.

First, this is a convoluted sentence, with too many negatives; second, you're burying the lede. The important point here is that DNSSEC is necessary, so put it up front: DNSSEC is necessary to detect forged responses, and without it any DNS response could be forged or altered. Unless the DNS responses have been validated with DNSSEC, a node cannot make a decision to prefer data from any interface with any great assurance.

-- Figures 5 and 6 -- Reserved: Field reserved for the future. MUST be set to zero.

It would seem to be useful for those future applications if we made sure that implementations didn't barf on receipt of some future value here. Would this work?: Reserved: Field reserved for the future. MUST be set to zero; MUST be ignored on receipt.

-- Figure 8 --Does this diagram tell me anything useful? If so, I can't figure out what. The only interesting part is in the "black box".

-- 10.2 -- An implementation may not be able to determine trust levels without explicit configuration provided by user or administrator.

OK, if you're going to go there, I have to: do you really think there's any serious possibility of user configuration here, especially in the case of a home-network user? I think that if you mention user configuration, you have to mention that in many, if not most, scenarios, user configuration is not a realistic possibility, and administrator configuration and policy heuristics are usually the only viable mechanisms.

========Other comments; no need to respond to these. Take them or modify themas you please:

"timeout" should be one word, not two (but "timed out" is, correctly, two).

-- 4.1 -- The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes resources such as energy. The amount of wasted energy can be significant, for example when radio interfaces has to be started just for the queries.

Maybe it's just an artifact of where the page break happened, but I wondered what the "energy" thing was until I saw "radio interfaces" (on the next page). I suggest using "power" rather than "energy", and specifically noting battery-powered and constrained environments. Perhaps this: The resolver SHOULD avoid sending queries over different network interfaces in parallel as that wastes resources such as power (in the case of battery powered and constrained environments). The wasted power can be significant: consider starting multiple radio interfaces just for parallel DNS queries.

2012-06-14

09

Barry Leiba

[Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba

The IESG has received a request from the Multiple Interfaces WG (mif) toconsider the following document:- 'Improved Recursive DNS Server Selection for Multi-Interfaced Nodes' as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2012-06-08. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning of the Subject line to allow automated sorting.

Abstract

A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions.

[Ballot Position Update] New position, Yes, has been recorded for Ralph Droms

2012-05-25

09

Ralph Droms

Created "Approve" ballot

2012-05-25

09

Ralph Droms

Last call announcement was changed

2012-05-25

09

Ralph Droms

Last call announcement was generated

2012-05-25

09

Teemu Savolainen

New version available: draft-ietf-mif-dns-server-selection-09.txt

2012-05-21

08

Ralph Droms

Last call announcement was generated

2012-05-17

08

Ralph Droms

Last call announcement was generated

2012-04-26

08

Ralph Droms

Ballot writeup was changed

2012-04-26

08

Ralph Droms

Ballot writeup was generated

2012-04-26

08

Ralph Droms

State changed to AD Evaluation from Publication Requested

2012-04-24

08

Cindy Morgan

(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or Historic)? Whyis this the proper type of ...

(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or Historic)? Whyis this the proper type of RFC? Is this type of RFC indicated in thetitle page header?==> Proposed Standard, this document is a normaltive work and request IANAto assign two new option codes, in the title page header states "Standards Track"

(2) The IESG approval announcement includes a Document AnnouncementWrite-Up. Please provide such a Document Announcement Write-Up. Recentexamples can be found in the "Action" announcements for approveddocuments. The approval announcement contains the following sections:Technical Summary==>A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions.

Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?==> There is no controversy about this document, but There were fears that this document is actually ¡°promoting use of split-brain DNS¡±. After discussions the concern was tackled in Section 7 ¡°Considerations for network administrators¡± with text: ¡±Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding caching related issues and destination selection problems (see Section 2.3).¡± Another major area that caused lots of discussion was security implications caused by risks related to attacker redirecting some DNS queries to bad places. This is addressed in Section 4.4. ¡°Limitations on use¡± and in Section 4.1, especially with help of DNSSEC.

Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?==> There are two implementations of the protocol, one fromNokia, the other from NTT. Microsoft also has Name ResolutionPolicy Table implementation. There are thorough review, but notlead to important changes, there is no substntive issues.There are no MID and Media type definition which need expert review.Personnel

Hui Deng is the Document Shepherd, Ralph Drom is the Responsible Area Director

(3) Briefly describe the review of this document that was performed bythe Document Shepherd. If this version of the document is not readyfor publication, please explain why the document is being forwarded tothe IESG.==¡· The document has been discussed in the working group which has wonthe concenuss to move forward this document.

(4) Does the document Shepherd have any concerns about the depth orbreadth of the reviews that have been performed? ==> The document has had extensive reviews within the IETF, not just MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have any concerns about the depth or breadth of reviews received.

(5) Do portions of the document need review from a particular or frombroader perspective, e.g., security, operational complexity, AAA, DNS,DHCP, XML, or internationalization? If so, describe the review thattook place. ==> The document has already got review from DNSEXT,DNSOP and DHCWG, others are not needed.

(6) Describe any specific concerns or issues that the Document Shepherdhas with this document that the Responsible Area Director and/or theIESG should be aware of? For example, perhaps he or she is uncomfortablewith certain parts of the document, or has concerns whether there reallyis a need for it. In any event, if the WG has discussed those issues andhas indicated that it still wishes to advance the document, detail thoseconcerns here. ==> There is no concern or issue on this document.

(7) Has each author confirmed that any and all appropriate IPRdisclosures required for full conformance with the provisions of BCP 78and BCP 79 have already been filed. If not, explain why. ==> There are 3 authors in this document, Teemu has conformed Nokia's IPR claimed. Ted has conformed he is not aware of any IPR. J. Kato from NTT didn't reply anything on this. Need IESG's advice on how to handle this.

(8) Has an IPR disclosure been filed that references this document?If so, summarize any WG discussion and conclusion regarding the IPRdisclosures. ==> Yes, it has an IPR disclosure before it has been adopted as the working group document, but there isn't one filed in the datatracker. working group feel that the terms in that IPR filing is acceptable.https://datatracker.ietf.org/ipr/1103/

(9) How solid is the WG consensus behind this document? Does itrepresent the strong concurrence of a few individuals, with othersbeing silent, or does the WG as a whole understand and agree with it? ==> WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extremediscontent? If so, please summarise the areas of conflict in separateemail messages to the Responsible Area Director. (It should be in aseparate email because this questionnaire is publicly available.) ==> No.

(11) Identify any ID nits the Document Shepherd has found in thisdocument. (See http://www.ietf.org/tools/idnits/ and the Internet-DraftsChecklist). Boilerplate checks are not enough; this check needs to bethorough. ==> the document has passed the ID nits check, no error and warning.

(12) D escribe how the document meets any required formal reviewcriteria, such as the MIB Doctor, media type, and URI type reviews. ==> This document meets the required criteria, and it doesn't define a new MIF, media type, and URL type.

(13) Have all references within this document been identified aseither normative or informative? ==> Yes.

(14) Are there normative references to documents that are not ready foradvancement or are otherwise in an unclear state? If such normativereferences exist, what is the plan for their completion? ==> No.

(15) Are there downward normative references references (see RFC 3967)?If so, list these downward references to support the Area Director in theLast Call procedure. ==> No.

(16) Will publication of this document change the status of anyexisting RFCs? Are those RFCs listed on the title page header, listedin the abstract, and discussed in the introduction? If the RFCs are notlisted in the Abstract and Introduction, explain why, and point to thepart of the document where the relationship of this document to theother RFCs is discussed. If this information is not in the document,explain why the WG considers it unnecessary. ==> No.

(17) Describe the Document Shepherd's review of the IANA considerationssection, especially with regard to its consistency with the body of thedocument. Confirm that all protocol extensions that the document makesare associated with the appropriate reservations in IANA registries.Confirm that any referenced IANA registries have been clearlyidentified. Confirm that newly created IANA registries include adetailed specification of the initial contents for the registry, thatallocations procedures for future registrations are defined, and areasonable name for the new registry has been sug gested (see RFC 5226). ==> Shepherd confirms that the document does request no new registries and pointers to existing registries

(18) List any new IANA registries that require Expert Review for futureallocations. Provide any public guidance that the IESG would finduseful in selecting the IANA Experts for these new registries. ==> the document doesn't request new registeries to existing registries

(19) Describe reviews and automated checks performed by the DocumentShepherd to validate sections of the document written in a formallanguage, such as XML code, BNF rules, MIB definitions, etc. ==> Shepherd think the document is well written in the formal language

(1) What type of RFC is being requested (BCP, Proposed Standard,Internet Standard, Informational, Experimental, or Historic)? Whyis this the proper type of RFC? Is this type of RFC indicated in thetitle page header?

==> Proposed Standard, this document is a normaltive work and request IANA to assign two new option codes, in the title page header states "Standards Track"

(2) The IESG approval announcement includes a Document AnnouncementWrite-Up. Please provide such a Document Announcement Write-Up. Recentexamples can be found in the "Action" announcements for approveddocuments. The approval announcement contains the following sections:

Technical Summary

==>A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions.

Working Group Summary

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

==> There is no controversy about this document, but There were fears that this document is actually “promoting use of split-brain DNS”. After discussions the concern was tackled in Section 7 “Considerations for network administrators” with text: ”Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding caching related issues and destination selection problems (see Section 2.3).”

Another major area that caused lots of discussion was security implications caused by risks related to attacker redirecting some DNS queries to bad places. This is addressed in Section 4.4. “Limitations on use” and in Section 4.1, especially with help of DNSSEC.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

==> There are two implementations of the protocol, one fromNokia, the other from NTT. Microsoft also has Name ResolutionPolicy Table implementation. There are thorough review, but notlead to important changes, there is no substntive issues.There are no MID and Media type definition which need expert review.

Personnel

Hui Deng is the Document Shepherd, Ralph Drom is the Responsible Area Director

(3) Briefly describe the review of this document that was performed bythe Document Shepherd. If this version of the document is not readyfor publication, please explain why the document is being forwarded tothe IESG.==》 The document has been discussed in the working group which has wonthe concenuss to move forward this document.

(4) Does the document Shepherd have any concerns about the depth orbreadth of the reviews that have been performed? ==> The document has had extensive reviews within the IETF, not just MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have any concerns about the depth or breadth of reviews received.

(5) Do portions of the document need review from a particular or frombroader perspective, e.g., security, operational complexity, AAA, DNS,DHCP, XML, or internationalization? If so, describe the review thattook place. ==> The document has already got review from DNSEXT,DNSOP and DHCWG, others are not needed.

(6) Describe any specific concerns or issues that the Document Shepherdhas with this document that the Responsible Area Director and/or theIESG should be aware of? For example, perhaps he or she is uncomfortablewith certain parts of the document, or has concerns whether there reallyis a need for it. In any event, if the WG has discussed those issues andhas indicated that it still wishes to advance the document, detail thoseconcerns here. ==> There is no concern or issue on this document.

(7) Has each author confirmed that any and all appropriate IPRdisclosures required for full conformance with the provisions of BCP 78and BCP 79 have already been filed. If not, explain why. ==> There are 3 authors in this document, Teemu has conformed Nokia's IPR claimed. Ted has conformed he is not aware of any IPR. J. Kato from NTT didn't reply anything on this. Need IESG's advice on how to handle this.

(8) Has an IPR disclosure been filed that references this document?If so, summarize any WG discussion and conclusion regarding the IPRdisclosures. ==> Yes, it has an IPR disclosure before it has been adopted as the working group document, but there isn't one filed in the datatracker. working group feel that the terms in that IPR filing is acceptable.https://datatracker.ietf.org/ipr/1103/

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with othersbeing silent, or does the WG as a whole understand and agree with it? ==> WG as a whole understand and agree with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separateemail messages to the Responsible Area Director. (It should be in aseparate email because this questionnaire is publicly available.) ==> No.

(11) Identify any ID nits the Document Shepherd has found in thisdocument. (See http://www.ietf.org/tools/idnits/ and the Internet-DraftsChecklist). Boilerplate checks are not enough; this check needs to bethorough. ==> the document has passed the ID nits check, no error and warning.

(12) Describe how the document meets any required formal reviewcriteria, such as the MIB Doctor, media type, and URI type reviews. ==> This document meets the required criteria, and it doesn't define a new MIF, media type, and URL type.

(13) Have all references within this document been identified aseither normative or informative? ==> Yes.

(14) Are there normative references to documents that are not ready foradvancement or are otherwise in an unclear state? If such normativereferences exist, what is the plan for their completion? ==> No.

(15) Are there downward normative references references (see RFC 3967)?If so, list these downward references to support the Area Director in theLast Call procedure. ==> No.

(16) Will publication of this document change the status of anyexisting RFCs? Are those RFCs listed on the title page header, listedin the abstract, and discussed in the introduction? If the RFCs are notlisted in the Abstract and Introduction, explain why, and point to thepart of the document where the relationship of this document to theother RFCs is discussed. If this information is not in the document,explain why the WG considers it unnecessary. ==> No.

(17) Describe the Document Shepherd's review of the IANA considerationssection, especially with regard to its consistency with the body of thedocument. Confirm that all protocol extensions that the document makesare associated with the appropriate reservations in IANA registries.Confirm that any referenced IANA registries have been clearlyidentified. Confirm that newly created IANA registries include adetailed specification of the initial contents for the registry, thatallocations procedures for future registrations are defined, and areasonable name for the new registry has been suggested (see RFC 5226). ==> Shepherd confirms that the document does request no new registries and pointers to existing registries

(18) List any new IANA registries that require Expert Review for futureallocations. Provide any public guidance that the IESG would finduseful in selecting the IANA Experts for these new registries. ==> the document doesn't request new registeries to existing registries

(19) Describe reviews and automated checks performed by the DocumentShepherd to validate sections of the document written in a formallanguage, such as XML code, BNF rules, MIB definitions, etc. ==> Shepherd think the document is well written in the formal language