headers
Thomas Narten | 2 Jan 2003 13:58
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt

> yep, I only did editorial nits, and tried to make it conformant with
> the ID nits. However, I did not split the references to normative
> and informative. The document is going to be Informational, and so I
> would guess that all references are informative by definition. (This
> would be my understanding.)

Whether a reference is normative or not has little to do with whether
a document is on standards track or not. It has to do with how
critical the reference is to understanding and/or implementing the
document at issue. I.e, if a document says, one SHOULD/MUST do foo, as
defined in RFC XXX, that is a normative reference, as one can't really
implement foo without having the referenced document at hand. It does
not matter whether the documents are or are not on the standards
track. 

Thus, it is useful to split references into info/normative in almost
all cases. This helps the *reader* better understand  whether the
reference is just informational or more important.

See draft-rfc-editor-rfc2223bis-03.txt.

Thomas
Permalink | Reply | 0 comments |
headers
Alain Durand | 4 Jan 2003 01:41
Picon

Re: Request to Publish ISATAP

Fred Templin wrote:

>Alain,
>
>Sorry for moving so quickly on this, but I submitted a -10.txt
>draft before seeing your message. It can be viewed at:
>
>  http://www.geocities.com/osprey67/isatap-10.txt
>  
>
This is somehow better, but there are still problems.
I hope you can fix them in -11.

   2.  There are no mandatory rules for the selection of a FQDN, but
       administrators are encouraged to use the convention
       "isatap.domainname" (e.g., isatap.example.com.)

The -10 draft says nothing on how this name is communicated
from the site Isatap administrator to the isatap nodes.
I guess the draft should say this is done by an out-of band
method,e.g. manual configuration.
If this is the case, then I would strongly recommend you add some
text to say that in the absence of configuration data,
implementations MUST NOT assume that isatap.domainame
will work, and in particular MUST provide a way for the user
to configure that parameter.

     - Alain.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alain Durand | 4 Jan 2003 02:51
Picon

Re: on NAT-PT


itojun@... wrote:

>>>you have been ignoring my comment (i made this comment months ago)
>>>to use "AD is secure" for the response from DNS-ALG.
>>>
>>>      
>>>
>>Let met get back to this now.
>>
>>The fundamental issue is that nodes do not know
>>about the potential presence of a DNS ALG,
>>so they can not decide if it is OK to do recursive
>>queries themselves or if they have to use "AD is secure"
>>and send DNS queries to a trusted recursive resolver.
>>    
>>
>
>	i guess you are talking about something different.
>
>	if the site administration policy is to use a recursive resolver
>	and "AD is secure", this does not matter whether the recursive
>	resolver is DNS-ALG or not.  the whole point of "AD is secure" is to
>	offload the implementation complexity of DNSSEC from the end clients
>	and put it into recursive resolver.
>
>itojun
>  
>
I think yes, were are talking about something different.
(Continue reading)

Permalink | Reply | 2 comments |
headers
itojun | 4 Jan 2003 02:18

Re: on NAT-PT

>>	so you don't apologize for attacking me on "product advertisement"?
>>	how nice.
>My words were too strong, but yours are sometime strong too.
>I guess this is because none of us are native english speaker.

	so you don't know how to apologize in English?

itojun
Permalink | Reply | 0 comments |
headers
itojun | 4 Jan 2003 02:18

Re: on NAT-PT

>>you have been ignoring my comment (i made this comment months ago)
>>to use "AD is secure" for the response from DNS-ALG.
>>
>Let met get back to this now.
>
>The fundamental issue is that nodes do not know
>about the potential presence of a DNS ALG,
>so they can not decide if it is OK to do recursive
>queries themselves or if they have to use "AD is secure"
>and send DNS queries to a trusted recursive resolver.

	i guess you are talking about something different.

	if the site administration policy is to use a recursive resolver
	and "AD is secure", this does not matter whether the recursive
	resolver is DNS-ALG or not.  the whole point of "AD is secure" is to
	offload the implementation complexity of DNSSEC from the end clients
	and put it into recursive resolver.

itojun
Permalink | Reply | 3 comments |
headers
itojun | 4 Jan 2003 05:33

Re: on NAT-PT

>>> What I'm saying is that imposing to use 'AD is secure'
>>> to operate DNSsec in IPv6 networks is a big step
>>> that I'm not sure I'm ready to make.
>> 	you are generalizing it too much by saying "in IPv6 networks" - what
>> 	i'm suggesting is to use "AD is secure" for NAT-PT, that's all.
>> 	it doesn't have to be imposed for all IPv6 networks.
>So you're back to my previous question. The context is now clearer, 
>thanks.
>How does the end node knows it is behind a NAT-PT box?

	end nodes do not need to know if it is behind a NAT-PT box or not.
	their connections will be invited to NAT-PT translation device by a
	matter of site administration policy (use specific recursive resolver),
	that's all.

	the use of "AD is secure" is not directly dependent to DNS-ALG, you
	could use it even when you are using normal recursive resolver.  i
	suggested the use of "AD is secure" because you asked how you can
	use DNSSEC with NAT-PT.

itojun
Permalink | Reply | 0 comments |
headers
Alain Durand | 3 Jan 2003 22:54
Picon

Re: Request to Publish ISATAP


Fred Templin wrote:

>Itojun,
>
>I will not go into the specifics of your message dated 12/24/02,
>but would ask that you review and comment on the latest version
>of the draft found at:
>
>  http://www.geocities.com/osprey67/isatap-09.txt
>

I still have a problem with the DNS solution in draft-09:

   When DNS fully-qualified domain names are used, IPv4 addresses for
   the PRL and SASL are discovered through a static host file or by
   querying an IPv4-based DNS server to resolve the domain names into
   address records (e.g., DNS 'A' resource records) containing IPv4
   addresses.  Unspecified alternative methods for domain name
   resolution may also be used.  The following notes apply when DNS
   fully-qualified domain names are used:

   1.  Site administrators maintain domain names and IPv4 addresses for
       the PRL and SASL for the site's ISATAP service, e.g., as address
       records in the site's name service.  Administrators may also
       advertise the domain names in a DHCPv4 option for ISATAP.

  ==> You are making the assumption that "site's name service" and
      "site's ISATAP service" have the same topology.
      This asumption is now always valid,for example at SUN
(Continue reading)

Permalink | Reply | 2 comments |
headers
itojun | 4 Jan 2003 03:00

Re: on NAT-PT

>I think yes, were are talking about something different.
>Yes, using 'AD is secure' works and solve the particular
>problem I'm describing.

	as far as i understand the use of recursive resolver (DNS-ALG) is part
	of the deal in NAT-PT.  so the point you made previously (nodes that
	make recursive query by themselves) are not covered/supported by NAT-PT.

>What I'm saying is that imposing to use 'AD is secure'
>to operate DNSsec in IPv6 networks is a big step
>that I'm not sure I'm ready to make.

	you are generalizing it too much by saying "in IPv6 networks" - what
	i'm suggesting is to use "AD is secure" for NAT-PT, that's all.
	it doesn't have to be imposed for all IPv6 networks.

itojun
Permalink | Reply | 1 comment |
headers
Alain Durand | 3 Jan 2003 19:21
Picon

Re: on NAT-PT


itojun@... wrote:

>	so you don't apologize for attacking me on "product advertisement"?
>	how nice.
>
My words were too strong, but yours are sometime strong too.
I guess this is because none of us are native english speaker.

Anyway, happy new year!

    - Alain.
Permalink | Reply | 1 comment |
headers
Fred Templin | 4 Jan 2003 01:25
Picon
Favicon

Re: Request to Publish ISATAP

Alain,

Sorry for moving so quickly on this, but I submitted a -10.txt
draft before seeing your message. It can be viewed at:

  http://www.geocities.com/osprey67/isatap-10.txt

while awaiting submission to the I-D repository. I think you will
find that this version addresses your concerns somewhat, but perhaps
not completely.

My expectation (and sincere hope) is that we can finalize all
remaining issues in a soon-to-be-released -11.txt draft. In the
meantime, please formalize any additional comments with reference
to -10.

Regards,

Fred Templin
osprey67@...

--- Alain Durand <Alain.Durand@...> wrote:
> I support Itojun's suggestion to drop all reference to DNS in this section.
> 
> 	- Alain.

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
(Continue reading)

Permalink | Reply | 1 comment |

Gmane