Re: TSVDIR Review for draft-ietf-netext-pmip6-lr-ps

[Yoshifumi Nishida]

Dear Marco,

Thanks for your response.

2011/5/2 Marco Liebsch :
> Dear Yoshifumi,
>
> thanks a lot for your review. Please find 2 comments inline.
>
> Yoshifumi Nishida wrote:
>>
>> Hello,
>> I've reviewed this document as part of the transport area
>> directorate's ongoing effort to review key IETF documents. These
>> comments were written primarily for the transport area directors, but
>> are copied to the document's authors for their information and to
>> allow them to address any issues raised. The authors should consider
>> this review together with any other last-call comments they
>> receive. Please always CC tsv-...@ietf.org if you reply to or forward
>> this review.
>>
>> Summary:
>>
>> This draft describes the problem space for localized routing in PMIPv6,
>> which supports direct communication between MAGs for MN and CN.
>> This draft is basically ready for publication and I couldn't
>> find any transport related issues in the draft.
>>
>> Minor comments:
>>
>> Would it be better to mention error detection and fallback function in
>> Functional Requirements? It would be useful and helpful to fall back
>> to normal routing when something happens.
>>
>
> I agree that the solution must provide means to handle such error cases
> and to step back to non-optimized routing in case there is need.
> I see these as non-functional requirements, whereas section 4 is about
> functional
> requirements only. We could add a functional requirement to 'terminate'
> localized routing. Example for reasons doing this could be the error
> case you mention. Does this sound ok?

Yes. That works for me.

>> I believe localize routing is very useful in most cases. However, I think
>> there will be the cases where we had better avoid localized routing,
>> such as a case where there are some restrictions (policy, network quality
>> or configuration, etc) in communications between MAGs.
>> It might be better to address having some kind of control to enable
>> localized routing in Functional Requirements in addition to checking
>> source and destination addresses.
>>
> Section 4, which covers the functional requirements, has a new item listed
> about enforcement of operator policies to control localized routing. I think
> that covers your comment.

I've checked the new item and I think it covers the comments.

Thanks,
--
Yoshifumi Nishida
nish...@sfc.wide.ad.jp
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[John Leslie]

Livingood, Jason  wrote:
> To: John Leslie ...
> 
> As I read it, this says that certain DNS servers will be configured
> to _not_ return  records to  queries by default.
> 
> This strikes me as a really-strange transition mechanism.
> 
> Depends on a number of factors for a content provider.

   Actually, no -- none of these factors make me feel it's any less than
_REALLY_ strange.

> The more traffic a domain receives the more likely they are to consider
> this practice as a transition mechanism from what I have observed.

   "Transition mechanism" is really-close to an oxymoron.

> This practice can give a large domain some level of control in turning
> on IPv6 access to their content, whereas they would lack this since
> they would turn it on for everyone when publishing the  RR in the
> DNS.

   It doesn't give nearly as much control as they seem to think it does.
This blocks  records, not based on the host interested in using them,
but based on some feature (IP address?) of the intermediate DNS resolver.
It's traditional to configure hosts to use two (or more) DNS resolvers
to mimimize the delays and disruptions.

   It will be very common for an end-host to alternate -requests
between one resolver which happens to be -blocked and another which
happens to be "whitelisted". I cringe in fear of taking the support
calls from such customers.

> Once a comfort level and operational stability is achieved I would
> expect most domains to move away from the practice, but that is TBD.

   I would expect a painful number of domains to forget it's there. :^(

> Certainly what happens on World IPv6 Day will bear on this question
> in important ways (when  RRs are published without the use of
> DNS whitelisting).

   I predict a majority will turn off  records for their regular
www.example.com on WorldIPv6Day+1.

   But that's OK: there are other ways to make progress.

   And the pressure should probably be applied to browser-software writers,
so that when an end-user finds himself IPv6-impaired, he can simply shift
to a different browser,

>Color me thoroghly confused.
> 
> Hopefully that's more over the practice than the document;

   Indeed, I _am_ more confused by the practice than the document.

   But the document is confusing enough! What does it encourage me to
_do_?

> if you wish to see improvements in the I-D just say so.

   Personally, I wish you'd do a nearly-global

s/DNS whitelisting/-blocking/

   It's a much more descriptive term.

   Also, I'd appreciate less of "this solve a transition problem" and
more of "this doesn't even do what the folks seem to think it does".

   It's arguably reasonable to -block to DNS resolvers whose
managers ask for it; but it's not at all reasonable to -block by
default. IMHO, it would be better to tell folks that ask you to
-block to switch to resolver software that can -block to
certain end-users. After all, the problem _isn't_ localized on the
DNS resolver.

   And the document does nothing to help me figure out what to do to
enable a venturesome customer to _use_ IPv6 to a site that turns on
this -blocking!

   :^( :^(

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

>Perhaps the document could include the arguments for and against this
>practice?  That way, someone who is new to IPv6
>deployment theory can quickly get up to speed.
>
>I'm very much in favor of documents which say "don't do this -- but if
>you have to, here's how."  But they have to include enough context for
>someone to understand why it'd be better if they didn't.

In the last update I added Section 9 "Is DNS Whitelisting a Recommended
Practice?"to attempt to address the question of "should a domain do this
or not?" (see 
http://tools.ietf.org/html/draft-ietf-v6ops-v6--whitelisting-implicatio
ns-03#section-9).

If folks here and on v6ops think it is valuable, I could add a sub-section
to this which addresses recommended things an implementer should do
(transparent/published policies, SLA on decision making, etc.).

Jason

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Andrew Sullivan]

On Mon, May 02, 2011 at 12:23:54PM -0700, J.D. Falk wrote:
> Perhaps the document could include the arguments for and against this 
> practice?  That way, someone who is new to IPv6 
> deployment theory can quickly get up to speed.
> 

On my reading, it does.  Whether people unfamiliar with the practice
find it clear enough is another matter.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[J.D. Falk]

On May 2, 2011, at 12:12 PM, Andrew Sullivan wrote:

> That this is a completely unscalable answer to the problem that a tiny
> percentage of computers on the Internet are misconfigured is something
> the people pushing this "whitelisting" acknowledge.  They're going to
> jump off that bridge when they get to it.  Right now, there's hardly
> any IPv6 penetration, they say, so they can handle it.
> 
> I think that this sort of "whitelisting" is, to be blunt,
> short-sighted and foolish, but I think it is better to have a document
> that at least explains what it is.  If we had a WCP series, I'd
> nominate this for inclusion.

Perhaps the document could include the arguments for and against this practice? 
 That way, someone who is new to IPv6 
deployment theory can quickly get up to speed.

I'm very much in favor of documents which say "don't do this -- but if you have 
to, here's how."  But they have to include enough context for someone to 
understand why it'd be better if they didn't.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Andrew Sullivan]

On Mon, May 02, 2011 at 01:08:38PM -0400, John Leslie wrote:
>As I read it, this says that certain DNS servers will be configured
> to _not_ return  records to  queries by default.

Yes, that's what the trick does.

>This strikes me as a really-strange transition mechanism.

Indeed.

The draft is, IMO, a little too diplomatic to say it, but what this
really comes down to is a boneheaded put-spackle-over-it answer to the
problem of previous failed transition mechanisms.

There are eyeballs out there in front of screens.  Those are the
things the content providers want to reach.

Some percentage of those eyeballs are looking at screens with bad or
misconfigured IPv6 connectivity.  But because they don't know that,
they'll ask for  records in their DNS lookups, because they think
they have IPv6 connecitivity.

What the "whitelisting" (scare quotes to address Dave's objection)
trick does is refuse to answer those  queries unless the operator
of the answering server has positive evidence to believe that the 
query is coming from a well-run IPv6 network.  If not, the  is
suppressed.  This causes the  lookups to fail, which causes the
bits to flow via IPv4.  The bits get to the eyeballs, and the content
provider is happy.

That this is a completely unscalable answer to the problem that a tiny
percentage of computers on the Internet are misconfigured is something
the people pushing this "whitelisting" acknowledge.  They're going to
jump off that bridge when they get to it.  Right now, there's hardly
any IPv6 penetration, they say, so they can handle it.

I think that this sort of "whitelisting" is, to be blunt,
short-sighted and foolish, but I think it is better to have a document
that at least explains what it is.  If we had a WCP series, I'd
nominate this for inclusion.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

   As I read it, this says that certain DNS servers will be configured
to _not_ return  records to  queries by default.

   This strikes me as a really-strange transition mechanism.

Depends on a number of factors for a content provider. The more traffic a 
domain receives the more likely they are to consider this practice as a 
transition mechanism from what I have observed. This practice can give a large 
domain some level of control in turning on IPv6 access to their content, 
whereas they would lack this since they would turn it on for everyone when 
publishing the  RR in the DNS. Once a comfort level and operational 
stability is achieved I would expect most domains to move away from the 
practice, but that is TBD. Certainly what happens on World IPv6 Day will bear 
on this question in important ways (when  RRs are published without the use 
of DNS whitelisting).

   Color me thoroghly confused.

Hopefully that's more over the practice than the document; if you wish to see 
improvements in the I-D just say so.

Thanks
Jason


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Livingood, Jason]

In any of the various IPv6 fora (including v6ops at the IETF) "DNS
Whitelisting" is how this practice is typically labeled. When writing the
draft I felt this could be confusing outside of IPv6 circles and so
lengthened it to "IPv6 DNS  Whitelisting" in the title.

In any case, "I don't like what it is called" is difficult to act on. ;-)
If there are recommendations on alternatives, I'm all ears.


Thanks
Jason




On 5/2/11 10:32 AM, "Richard L. Barnes"  wrote:

>I disagree that "whitelisting" is a reserved trademark of the anti-abuse
>community.  It's a general term for a list of things that are granted
>something.  Likewise with "blacklist" and "deny".  Which means it's
>perfectly appropriate for this document.
>
>
>
>
>
>On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote:
>
>> 
>> Review:
>> 
>> Title:  IPv6  DNS Whitelisting Implications
>> I-D:draft-ietf-v6ops-v6--whitelisting-implications-03
>> 
>> By: D. Crocker 
>> Date:   29 April 2011
>> 
>> 
>> Summary:
>> 
>> This draft is a discussion of a technique for resolving a dual-stack
>>problem between IPv4 and IPv6, through the use of special DNS records.
>> 
>> The document appears to continue a recent use of the term
>>'whitelisting' that strongly conflicts with long-standing use of the
>>term by the anti-abuse community.
>> 
>> The document needs to do a more careful job of introducing the problem
>>it is solving and the explaining the way the 'whitelisting' mechanism
>>works.
>> 
>> I also very strongly encourage finding a different term.
>> 
>> d/
>> 
>> 
>>> Abstract
>>> 
>>>   The objective of this document is to describe what the whitelisting
>>>   of DNS  resource records is, hereafter referred to as DNS
>> 
>> RRs are whitelisted?  Isn't it the addresses and not the records that
>>are whitelisted?
>> 
>> Does this mean putting whitelisting records into the DNS or does it
>>mean something else?
>> 
>> Comcast's own considerable expertise notwithstanding, has this doc been
>>vetted with a range of organizations that actually DO whitelisting?  Has
>>it been circulated through MAAWG and APWG?  Any comments from Spamhaus?
>>The Acknowledgements list does not seem to indicate a range of whitelist
>>ops folks whose names I know.  (But then, I only know a few...)
>> 
>> 
>>>   whitelisting, as well as the implications of this emerging practice
>>>   and what alternatives may exist.  The audience for this document is
>>>   the Internet community generally, including the IETF and IPv6
>>>   implementers.
>> 
>> I suspect that product marketers won't have much interest in this.  I
>>suspect that the target for this is anti-abuse technical and operations
>>staff.
>> 
>> 
>>> Status of this Memo
>>> 
>>>   This Internet-Draft is submitted in full conformance with the
>>>   provisions of BCP 78 and BCP 79.
>>> 
>>>   Internet-Drafts are working documents of the Internet Engineering
>>>   Task Force (IETF).  Note that other groups may also distribute
>>>   working documents as Internet-Drafts.  The list of current Internet-
>>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>>> 
>>>   Internet-Drafts are draft documents valid for a maximum of six months
>>>   and may be updated, replaced, or obsoleted by other documents at any
>>>   time.  It is inappropriate to use Internet-Drafts as reference
>>>   material or to cite them other than as "work in progress."
>>> 
>>>   This Internet-Draft will expire on August 26, 2011.
>>> 
>>> Copyright Notice
>>> 
>>>   Copyright (c) 2011 IETF Trust and the persons identified as the
>>>   document authors.  All rights reserved.
>>> 
>>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>>   Provisions Relating to IETF Documents
>>>   (http://trustee.ietf.org/license-info) in effect on the date of
>>>   publication of this document.  Please review these documents
>>>   carefully, as they describe your rights and restrictions with respect
>>>   to this document.  Code Components extracted from this document must
>>>   include Simplified BSD License text as described in Section 4.e of
>>>   the Trust Legal Provisions and are provided without warranty as
>>> 
>>> 
>>> 
>>> LivingoodExpires August 26, 2011[Page
>>>1]
>>> 
>>> Internet-Draft   IPv6  DNS Whitelisting Implications   February
>>>2011
>>> 
>>> 
>>>   described in the Simplified BSD License.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> LivingoodExpires August 26, 2011[Page
>>>2]
>>> 
>>> Internet-Draft   IPv6  DNS Whitelisting Implications   February
>>>2011
>>> 
>>> 
>>> Table of Contents
>>> 
>>>   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
>>>   2.  How DNS Whitelisting 

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[John Leslie]

Richard L. Barnes  wrote:
> 
> Search on "whitelist ipv6".  Results are topical.

   Indeed, folks are talking about "ipv6 whitelist" right now; and I
guess they're referring to the same thing this I-D discusses...

> What's the conflict here?

   What does "ipv6 whitelist" mean to the average reader?

   Most of the links I found were considerably less helpful than the
I-D itself. Hopefully they are discussing what this I-D specifies, but
I'm not entirely certain...
" 
" When implemented, DNS whitelisting in practice means that a domain's
" authoritative DNS will return a  resource record to DNS recursive
" resolvers [RFC1035] on the whitelist, while returning no 
" resource records to DNS resolvers which are not on the whitelist.

   As I read it, this says that certain DNS servers will be configured
to _not_ return  records to  queries by default.

   This strikes me as a really-strange transition mechanism.

   Color me thoroghly confused.

--
John Leslie 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Dave CROCKER]

Richard,

Oh, right.  Sorry, I thought the reference to  had to do with the DNS.

Clearly, since it will only be used in the context of v6, it won't cause any 
confusion.


My own having mistaken the title of the document as being the longstanding use 
of the term for DNS Whitelisting of anti-abuse-related addresses was merely an 
exception.


d/

On 5/2/2011 8:46 AM, Richard L. Barnes wrote:

Search on "whitelist ipv6".  Results are topical.  What's the conflict here?

On May 2, 2011, at 5:01 PM, Dave CROCKER wrote:

On 5/2/2011 7:32 AM, Richard L. Barnes wrote:

I disagree that "whitelisting" is a reserved trademark of the anti-abuse community.  It's a general 
term for a list of things that are granted something.  Likewise with "blacklist" and 
"deny".  Which means it's perfectly appropriate for this document.




Richard,

The trademark model is interesting and probably useful here.

Trademarks have context.
Search on "whitelist dns"
Since there is long-standing practice of anti-abuse use of the term for A 
records there as no doubt it would be -- and indeed is -- need to use it for 
 records.


--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Richard L. Barnes]

Search on "whitelist ipv6".  Results are topical.  What's the conflict here?


On May 2, 2011, at 5:01 PM, Dave CROCKER wrote:

> 
> 
> On 5/2/2011 7:32 AM, Richard L. Barnes wrote:
>> I disagree that "whitelisting" is a reserved trademark of the anti-abuse 
>> community.  It's a general term for a list of things that are granted 
>> something.  Likewise with "blacklist" and "deny".  Which means it's 
>> perfectly appropriate for this document.
>> 
>> 
> 
> 
> Richard,
> 
> The trademark model is interesting and probably useful here.
> 
> Trademarks have context.
> 
> Search on "whitelist dns"
> 
> Since there is long-standing practice of anti-abuse use of the term for A 
> records there as no doubt it would be -- and indeed is -- need to use it for 
>  records.
> 
> d/
> 
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Dave CROCKER]

On 5/2/2011 7:32 AM, Richard L. Barnes wrote:

I disagree that "whitelisting" is a reserved trademark of the anti-abuse community.  It's a general 
term for a list of things that are granted something.  Likewise with "blacklist" and 
"deny".  Which means it's perfectly appropriate for this document.





Richard,

The trademark model is interesting and probably useful here.

Trademarks have context.

Search on "whitelist dns"

Since there is long-standing practice of anti-abuse use of the term for A 
records there as no doubt it would be -- and indeed is -- need to use it for 
 records.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[Richard L. Barnes]

I disagree that "whitelisting" is a reserved trademark of the anti-abuse 
community.  It's a general term for a list of things that are granted 
something.  Likewise with "blacklist" and "deny".  Which means it's perfectly 
appropriate for this document.





On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote:

> 
> Review:
> 
> Title:  IPv6  DNS Whitelisting Implications
> I-D:draft-ietf-v6ops-v6--whitelisting-implications-03
> 
> By: D. Crocker 
> Date:   29 April 2011
> 
> 
> Summary:
> 
> This draft is a discussion of a technique for resolving a dual-stack problem 
> between IPv4 and IPv6, through the use of special DNS records.
> 
> The document appears to continue a recent use of the term 'whitelisting' that 
> strongly conflicts with long-standing use of the term by the anti-abuse 
> community.
> 
> The document needs to do a more careful job of introducing the problem it is 
> solving and the explaining the way the 'whitelisting' mechanism works.
> 
> I also very strongly encourage finding a different term.
> 
> d/
> 
> 
>> Abstract
>> 
>>   The objective of this document is to describe what the whitelisting
>>   of DNS  resource records is, hereafter referred to as DNS
> 
> RRs are whitelisted?  Isn't it the addresses and not the records that are 
> whitelisted?
> 
> Does this mean putting whitelisting records into the DNS or does it mean 
> something else?
> 
> Comcast's own considerable expertise notwithstanding, has this doc been 
> vetted with a range of organizations that actually DO whitelisting?  Has it 
> been circulated through MAAWG and APWG?  Any comments from Spamhaus?  The 
> Acknowledgements list does not seem to indicate a range of whitelist ops 
> folks whose names I know.  (But then, I only know a few...)
> 
> 
>>   whitelisting, as well as the implications of this emerging practice
>>   and what alternatives may exist.  The audience for this document is
>>   the Internet community generally, including the IETF and IPv6
>>   implementers.
> 
> I suspect that product marketers won't have much interest in this.  I suspect 
> that the target for this is anti-abuse technical and operations staff.
> 
> 
>> Status of this Memo
>> 
>>   This Internet-Draft is submitted in full conformance with the
>>   provisions of BCP 78 and BCP 79.
>> 
>>   Internet-Drafts are working documents of the Internet Engineering
>>   Task Force (IETF).  Note that other groups may also distribute
>>   working documents as Internet-Drafts.  The list of current Internet-
>>   Drafts is at http://datatracker.ietf.org/drafts/current/.
>> 
>>   Internet-Drafts are draft documents valid for a maximum of six months
>>   and may be updated, replaced, or obsoleted by other documents at any
>>   time.  It is inappropriate to use Internet-Drafts as reference
>>   material or to cite them other than as "work in progress."
>> 
>>   This Internet-Draft will expire on August 26, 2011.
>> 
>> Copyright Notice
>> 
>>   Copyright (c) 2011 IETF Trust and the persons identified as the
>>   document authors.  All rights reserved.
>> 
>>   This document is subject to BCP 78 and the IETF Trust's Legal
>>   Provisions Relating to IETF Documents
>>   (http://trustee.ietf.org/license-info) in effect on the date of
>>   publication of this document.  Please review these documents
>>   carefully, as they describe your rights and restrictions with respect
>>   to this document.  Code Components extracted from this document must
>>   include Simplified BSD License text as described in Section 4.e of
>>   the Trust Legal Provisions and are provided without warranty as
>> 
>> 
>> 
>> LivingoodExpires August 26, 2011[Page 1]
>> 
>> Internet-Draft   IPv6  DNS Whitelisting Implications   February 2011
>> 
>> 
>>   described in the Simplified BSD License.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> LivingoodExpires August 26, 2011[Page 2]
>> 
>> Internet-Draft   IPv6  DNS Whitelisting Implications   February 2011
>> 
>> 
>> Table of Contents
>> 
>>   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
>>   2.  How DNS Whitelisting Works . . . . . . . . . . . . . . . . . .  6
>> 2.1.  Description of the Operation of DNS Whitelisting . . . . .  7
>>   3.  What Problems Are Implementers Trying To Solve?  . . . . . . .  8
>>   4.  Concerns Regarding DNS Whitelisting  . . . . . . . . . . . . .  9
>>   5.  Similarities to Other DNS Operations . . . . . . . . . . . . . 12
>> 5.1.  Similarities to Split DNS  . . . . . . . . . . . . . . . . 12
>> 5.2.  Similarities to DNS Load Balancing . . . . . . . . . . . . 12
>>   6.  Likely Deployment Scenarios  . . . . . . . . . . . . . . . . . 13
>> 6.1.  Deploying DNS Whitelisting On An Ad Hoc Ba

Re: TSVDIR Review for draft-ietf-netext-pmip6-lr-ps

[Marco Liebsch]

Dear Yoshifumi,

thanks a lot for your review. Please find 2 comments inline.

Yoshifumi Nishida wrote:

Hello,
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC tsv-...@ietf.org if you reply to or forward
this review.

Summary:

This draft describes the problem space for localized routing in PMIPv6,
which supports direct communication between MAGs for MN and CN.
This draft is basically ready for publication and I couldn't
find any transport related issues in the draft.

Minor comments:

Would it be better to mention error detection and fallback function in
Functional Requirements? It would be useful and helpful to fall back
to normal routing when something happens.
  

I agree that the solution must provide means to handle such error cases
and to step back to non-optimized routing in case there is need.
I see these as non-functional requirements, whereas section 4 is about 
functional

requirements only. We could add a functional requirement to 'terminate'
localized routing. Example for reasons doing this could be the error
case you mention. Does this sound ok?



I believe localize routing is very useful in most cases. However, I think
there will be the cases where we had better avoid localized routing,
such as a case where there are some restrictions (policy, network quality
or configuration, etc) in communications between MAGs.
It might be better to address having some kind of control to enable
localized routing in Functional Requirements in addition to checking
source and destination addresses.
  

Section 4, which covers the functional requirements, has a new item listed
about enforcement of operator policies to control localized routing. I think
that covers your comment.

Thanks and best regards,
marco



Thanks,
--
Yoshifumi Nishida
nish...@sfc.wide.ad.jp
  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

[SM]

Hi Dave,
At 16:32 29-04-2011, Dave CROCKER wrote:

Review:

Title:  IPv6  DNS Whitelisting Implications
I-D:draft-ietf-v6ops-v6--whitelisting-implications-03


I have this document on the list of assignments to be made.  I 
generally avoid doing a review of a document on which I have 
previously commented.  Would you like to take on the assignment?


Please do feel free to decline or else I won't ask. :-)

Best regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART LC review of RFC5591 to DS

[Ben Campbell]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at .

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: RFC5591 and report-rfc5343-5590-5591-5953.txt
Reviewer: Ben Campbell  
Review Date: 2011-04-29
IETF LC End Date: 2011-05-03

Summary: RFC5591 is likely ready to progress to draft standard. However, there 
are some features of the RFC for which it is not clear to me if they have been 
sufficiently tested.

Major issues:

None

Minor issues:

Section 6 of the interoperability report describes a failure to interop due to 
one implementation incorrectly not setting the security parameters of a 
response to match those of the request. The report recognized that 
implementations should do this--but I must point out this is a MUST level 
requirement in RFC5591. The report recognized that this was an implementation 
bug. But the report does not explicitly indicate whether a successful test when 
(and if) the bug was fixed. (I can only assume it was fixed and retested, since 
this would seem to block the other test results.)

Both section 6 and 7 of the interoperability report list the 
snmpTsmConfigurationUsePrefix configuration feature as untestable or untested. 
It's not clear to me why this was considered untestable, and I am agnostic on 
whether it's okay to progress without testing this feature. I mention it only 
to to make sure people better suited to judge the subtleties have noticed and 
thought about it.

Nits/editorial comments:

None
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Gen-art] review: draft-ietf-netext-pmip6-lr-ps-05

[Marco Liebsch]

Dear Joel,

thanks a lot for your valuable comments. Please find below a revised 
Abstract and Introduction.

I marked new text as follows: /+ new or revised text +/

Please let me know if the proposed revision makes the scope of the 
document clearer.


---
Abstract

  Proxy Mobile IPv6 is the IETF standard for network-based mobility
  management.  In Proxy Mobile IPv6, mobile nodes are topologically
  anchored at a Local Mobility Anchor, which forwards all data for
  registered mobile nodes. /+ The setup and maintenance of localized
  routing, which allows forwarding of data packets between two mobile
  nodes' Mobility Access Gateways without involvement of their Local
  Mobility Anchor in forwarding, is not considered. +/ This document
  describes the problem space of localized routing in Proxy Mobile
  IPv6.

---1.  Introduction

  The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the
  base protocol for network-based localized mobility management
  (NetLMM).  The scope of the base protocol covers the set up and
  maintenance of a tunnel between an MN's Mobile Access Gateway (MAG)
  and its selected Local Mobility Anchor (LMA).  Data packets will
  always traverse the MN's MAG and its LMA, irrespective of the
  location of the MN's remote communication endpoint.  Even though an
  MN may be attached to the same or a different MAG as its
  Correspondent Node (CN) within the same provider domain, packets
  being associated with their communication will traverse the MN's and
  the CN's LMA /+, which can be located topologically far away from the
  MN's and the CN's MAG or even in a separate provider domain.+/
  [RFC5213] addresses the need to enable local routing of traffic
  between two nodes being attached to the same MAG, but does not
  specify the complete procedure to establish such localized routing
  state on the shared MAG.

  The NetLMM Extensions (NetExt) Working Group has an objective to
  design a solution for localized routing in PMIPv6.  This includes the
  specification of protocol messages and associated protocol operation
  between PMIPv6 components to support the setup of a direct routing
  path for data packets between the MN's and the CN's MAG /+, both
  receiving mobility service according to the PMIPv6 protocol
  [RFC5213] +/.  As a result of localized routing, these packets will be
  forwarded between the two associated MAGs without traversing the MN's
  and the CN's LMA(s).  In case one or both nodes hand over to a
  different MAG, the localized routing protocol maintains the localized
  routing path.  Relevant protocol interfaces may include the interface
  between associated MAGs, between a MAG and an LMA as well as between
  LMAs. /+ Out of scope of the NetExt solution and this problem statement
  is the setup of localized routing with CNs, which are not registered
  with a PMIPv6 network. +/

  This document analyzes and discusses the problem space of using
  always the default route through two communicating mobile nodes'
  local mobility anchors.  Furthermore, the problem space of enabling
  localized routing in PMIPv6 is analyzed and described, while
  different communication and mobility scenarios are taken into
  account. /+ Based on the analysis, a list of key functional
  requirements is provided, serving as input to the design of the
  protocol solution.+/


Best regards,
Marco










Joel M. Halpern wrote:
I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
.


Please resolve these comments along with any other Last Call comments 
you may receive.


Document: draft-ietf-netext-pmip6-lr-ps-05
PMIPv6 Localized Routing Problem Statement
Reviewer: Joel M. Halpern
Review Date: 7-March-2011
IETF LC End Date: 14-March-2011
IESG Telechat date: 17-March-2011

Summary: This document is close to ready for publication as an 
Informational RFC.


Moderate issues:
The abstract is misleading.  It reads as if the problem is 
allowing communication between a PMIP mobile node and a correspondent, 
wherever the correspondent is.  Even the introduction is somewhat hazy 
on its scope, sometimes referring to the generalized notion of 
correspondent node, and sometimes seeming to mean just the sub-case of 
two nodes, both attached to MAGs, in the same domain.  It is only in 
the conventions and terminology that "Localized Routing" is actually 
defined in a way to make clear what problem is of interest.



Minor issues:
In the introduction, the word "problem space" is used to describe 
what is being covered in this document.  However, the document 
includes sections such as section 4, Functional Requirements for 
Localized Routing which are not about the problem, but rather about 
what mechanisms are needed for a solution.  Rather than argue about 
what belongs in this document, or the document name, I would suggest 
clarifying in the introduction what this do

Re: Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard

[Mykyta Yevstifeyev]

02.05.2011 11:44, Magnus Westerlund wrote:

Hi,

When the last call has ended I will update the draft with the changes
identified.

Thanks for considering and intention to incorporate my comments.

Mykyta Yevstifeyev

Mykyta Yevstifeyev skrev 2011-04-29 18:04:

Magnus,

29.04.2011 11:47, Magnus Westerlund wrote:

Hi Mykyta,

Thanks for the review.

See inline for response.

Mykyta Yevstifeyev skrev 2011-04-28 19:22:

Hello,

Some comments on this document, currently in Last Call.


Network Working Group  M. Westerlund
Internet-Draft  Ericsson
Updates: 5245 (if approved)   C. Perkins
Intended status: Standards Track   University of Glasgow
Expires: September 29, 2011   March 28, 2011

I don't see why the intended status for this document is Standards
Track.  Wouldn't Informational be enough?  Could you please justify why
have you chosen it?

I don't think we have put much thought into it. But one reason I can
think of is to have it on the same maturity level as the ICE
specification itself. Thus enabling a merge of this registry into an
update of RFC 5245 without forcing it to be recycled as proposed.

This is a good reason, so I'll agree with it.

Ok


Your registry description does not mention what is the precise name of
the registry.  While everybody understands that is sands for ICE
options, it would be useful to give IANA distinctive guidelines on its
name (this is also required in RFC5226, Section 4.2, 1) in the list;
http://tools.ietf.org/html/rfc5226#section-4.2).

Yes, I agree that it should be included in Section 3.1 of our document
rather than only in the title which says "Interactive Connectivity
Establishment (ICE) Options"

Agreed on this.  Such name is fine, IMO.

Ok


   From RFC 5226, also Section 4.2:


   5) Initial assignments and reservations.  Clear instructions
   should be provided to identify any initial assignments or
   registrations.  In addition, any ranges that are to be reserved
   for "Private Use", "Reserved", "Unassigned", etc. should be
   clearly indicated.

Are there any initial assignments?  Your document mentions one option;
shouldn't it be registered?

No, because when draft-ietf-avtcore-rtp-ecn gets published that will
actually do the registration. As that document isn't approved yet and in
fact still not WG last called this registry will first be created empty
and then populated.

So you should have mentioned this in the draft as well.

Ok, will clarify.


   A registration request MUST include the following information:

 [ . . . ]

Shall this be mentioned as a registration template?

It isn't written as one. It is a list of what needs to be present in the
registration. And I think a template would be more focused on what needs
to the general categories rather than the information. Thus I don't want
this as registration template.

OK, this matter is not very important.

o  Email and Address of the Contact person

I think you should add the name of the contact person to the name of
this field as well.

As the two first bullets are:

 o  Name of contact person for the registration

 o  Email and Address of the Contact person

I don't quite understand your comment. Do you want us to merge the two
entries? This as the contact persons will need to provide name, email
and address. I am fine with merging them and this is likely a slight
improvement.

No, I didn't propose to merge it.  I just proposed to rename this field
as "Name, Email and Addresses of the Contact Person".

I think it is logical to have only one entry saying:

"Name, Email and Addresses of the Contact Person for the registration"

Cheers

Magnus Westerlund

--
Multimedia Technologies, Ericsson Research EAB/TVM
--
Ericsson AB| Phone  +46 10 7148287
Färögatan 6| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com
--



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard

[Magnus Westerlund]

Hi,

When the last call has ended I will update the draft with the changes
identified.

Mykyta Yevstifeyev skrev 2011-04-29 18:04:
> Magnus,
> 
> 29.04.2011 11:47, Magnus Westerlund wrote:
>> Hi Mykyta,
>>
>> Thanks for the review.
>>
>> See inline for response.
>>
>> Mykyta Yevstifeyev skrev 2011-04-28 19:22:
>>> Hello,
>>>
>>> Some comments on this document, currently in Last Call.
>>>
 Network Working Group  M. Westerlund
 Internet-Draft  Ericsson
 Updates: 5245 (if approved)   C. Perkins
 Intended status: Standards Track   University of Glasgow
 Expires: September 29, 2011   March 28, 2011
>>> I don't see why the intended status for this document is Standards
>>> Track.  Wouldn't Informational be enough?  Could you please justify why
>>> have you chosen it?
>> I don't think we have put much thought into it. But one reason I can
>> think of is to have it on the same maturity level as the ICE
>> specification itself. Thus enabling a merge of this registry into an
>> update of RFC 5245 without forcing it to be recycled as proposed.
> This is a good reason, so I'll agree with it.

Ok

>>> Your registry description does not mention what is the precise name of
>>> the registry.  While everybody understands that is sands for ICE
>>> options, it would be useful to give IANA distinctive guidelines on its
>>> name (this is also required in RFC5226, Section 4.2, 1) in the list;
>>> http://tools.ietf.org/html/rfc5226#section-4.2).
>>
>> Yes, I agree that it should be included in Section 3.1 of our document
>> rather than only in the title which says "Interactive Connectivity
>> Establishment (ICE) Options"
> Agreed on this.  Such name is fine, IMO.

Ok

>>>  From RFC 5226, also Section 4.2:
>>>
   5) Initial assignments and reservations.  Clear instructions
   should be provided to identify any initial assignments or
   registrations.  In addition, any ranges that are to be reserved
   for "Private Use", "Reserved", "Unassigned", etc. should be
   clearly indicated.
>>> Are there any initial assignments?  Your document mentions one option;
>>> shouldn't it be registered?
>> No, because when draft-ietf-avtcore-rtp-ecn gets published that will
>> actually do the registration. As that document isn't approved yet and in
>> fact still not WG last called this registry will first be created empty
>> and then populated.
> So you should have mentioned this in the draft as well.

Ok, will clarify.

   A registration request MUST include the following information:

 [ . . . ]
>>> Shall this be mentioned as a registration template?
>> It isn't written as one. It is a list of what needs to be present in the
>> registration. And I think a template would be more focused on what needs
>> to the general categories rather than the information. Thus I don't want
>> this as registration template.
> OK, this matter is not very important.
 o  Email and Address of the Contact person
>>> I think you should add the name of the contact person to the name of
>>> this field as well.
>> As the two first bullets are:
>>
>> o  Name of contact person for the registration
>>
>> o  Email and Address of the Contact person
>>
>> I don't quite understand your comment. Do you want us to merge the two
>> entries? This as the contact persons will need to provide name, email
>> and address. I am fine with merging them and this is likely a slight
>> improvement.
> No, I didn't propose to merge it.  I just proposed to rename this field 
> as "Name, Email and Addresses of the Contact Person".

I think it is logical to have only one entry saying:

"Name, Email and Addresses of the Contact Person for the registration"

Cheers

Magnus Westerlund

--
Multimedia Technologies, Ericsson Research EAB/TVM
--
Ericsson AB| Phone  +46 10 7148287
Färögatan 6| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com
--
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf