Re: v4v6interim <at> ietf.org Mailing list

Sorry - the correct name should be

v4v6coexistence

I just updated the wiki

On Oct 1, 2008, at 9:23 , Stark, Barbara wrote:

> Could someone confirm the name of the jabber room? My client tells  
> me that "v4v6existence" doesn't exist.
> Barbara
>
> -----Original Message-----
> From: owner-v6ops <at> ops.ietf.org [mailto:owner-v6ops <at> ops.ietf.org] On  
> Behalf Of Dan Wing
> Sent: Tuesday, September 30, 2008 7:49 AM
> To: 'Narayanan, Vidya'; 'Mark Townsley'; 'Margaret Wasserman'
> Cc: 'Brian Haberman'; 'Internet Area'; softwires <at> ietf.org; 'IPv6  
> Operations'; ipv6 <at> ietf.org; 'Behave WG'; v4v6interim <at> ietf.org
> Subject: RE: v4v6interim <at> ietf.org Mailing list
>
> See the "Remote Participation" section at:
> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>
> Please register for remote participation, so we have a feeling of  
> how many
> people are supposed to be in the jabber room and on the conference  
> bridge.
>

v4v6interim@... Mailing list

Could someone confirm the name of the jabber room? My client tells me that "v4v6existence" doesn't exist.
Barbara

-----Original Message-----
From: owner-v6ops@...
[mailto:owner-v6ops@...] On Behalf Of Dan Wing
Sent: Tuesday, September 30, 2008 7:49 AM
To: 'Narayanan, Vidya'; 'Mark Townsley'; 'Margaret Wasserman'
Cc: 'Brian Haberman'; 'Internet Area'; softwires@...; 'IPv6 Operations';
ipv6@...; 'Behave WG'; v4v6interim@...
Subject: RE: v4v6interim@... Mailing list

See the "Remote Participation" section at:
http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim

Please register for remote participation, so we have a feeling of how many
people are supposed to be in the jabber room and on the conference bridge.

-d

> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan@...] 
> Sent: Tuesday, September 30, 2008 12:04 AM
> To: Mark Townsley; Margaret Wasserman
> Cc: Brian Haberman; Internet Area; softwires@...; Dan 
> Wing; 'IPv6 Operations'; ipv6@...; Behave WG
> Subject: RE: v4v6interim@... Mailing list
> 
> Mark,
> Please share the remote particpation info (jabber room, audio 

v4v6interim@... Mailing list

v4v6coexistence

On 2/10/2008, at 2:23 AM, Stark, Barbara wrote:

> Could someone confirm the name of the jabber room? My client tells  
> me that "v4v6existence" doesn't exist.
> Barbara
>
> -----Original Message-----
> From: owner-v6ops@...
[mailto:owner-v6ops@...] On  
> Behalf Of Dan Wing
> Sent: Tuesday, September 30, 2008 7:49 AM
> To: 'Narayanan, Vidya'; 'Mark Townsley'; 'Margaret Wasserman'
> Cc: 'Brian Haberman'; 'Internet Area'; softwires@...; 'IPv6  
> Operations'; ipv6@...; 'Behave WG'; v4v6interim@...
> Subject: RE: v4v6interim@... Mailing list
>
> See the "Remote Participation" section at:
> http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>
> Please register for remote participation, so we have a feeling of  
> how many
> people are supposed to be in the jabber room and on the conference  
> bridge.
>
> -d
>
>
>> -----Original Message-----

WGLC: draft-ietf-behave-nat-icmp-09

Hi.  In BEHAVE we are trying to nail down ICMP requirements for a NAT.  As you
can see from my email below, the document was revised and is now much more
specific and indicates MUST/MAY/SHOULD NOT for various ICMP messages.

Please let us know if these recommendations seem (un)reasonable for a NAT by
sending email to behave <at> ietf.org.

Thanks,
-Dan Wing, BEHAVE co-chair

-----Original Message-----
From: Dan Wing [mailto:dwing <at> cisco.com] 
Sent: Tuesday, October 07, 2008 1:29 PM
To: 'Behave WG'
Cc: 'behave-chairs <at> tools.ietf.org'
Subject: WGLC: draft-ietf-behave-nat-icmp-09 

During IESG evaluation a DISCUSS was raised regarding the Section 4.3 RFC1812
conformance requirement.  As a result section 7.0 of
draft-ietf-behave-nat-icmp-09 was changed to specify which ICMP messages need
to be supported by a NAT.  The new text from -09 is below, and you can also
find it at:

http://tools.ietf.org/html/draft-ietf-behave-nat-icmp-09
and side-by-side diffs are available by clicking "Diff2".

The DISCUSS can be found at
https://datatracker.ietf.org/idtracker/draft-ietf-behave-nat-icmp/

I expect there may be some reaction to certain ICMP messages being in the

Re: [Int-area] WGLC: draft-ietf-behave-nat-icmp-09

At 05:31 p.m. 07/10/2008, Dan Wing wrote:

>    REQ-9: A NAT device MAY implement a policy control that prevents
>    ICMP messages being generated toward certain interface(s).
>    Implementation of such a policy control overrides the MUSTs in
>    REQ-10.

Then.... shouldn't the requirements be "SHOULD"s rather than "MUST"s?

>    REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to
>    support ICMP messages as below, some conforming to Section 4.3 of
>    [RFC1812] and some superseding the requirements of Section 4.3 of
>    [RFC1812].
>        a. MUST support:
>          1. Destination Unreachable Message, as described in
>              Section 7.1 of this document,
>           2. Time Exceeded Message, as described in Section 7.2 of
>              of this document,
>           3. Parameter Problem Message, as described in
>              Section 4.3.3.5 of [RFC1812],
>           4. Echo Request/Reply Messages, as described in REQ-1,
>           5. Router Advertisement and Solicitations, as described in
>              Section 4.3.3.10 of [RFC1812].

Does anybody actually use these ICMPv4 messages? I do recall Windows 
systems sending these messages when they are bootstrapped, but...

>        b. MAY support:
>           1. Redirect Message, as described in Section 4.3.3.2 of
>              [RFC1812],

Re: [Int-area] WGLC: draft-ietf-behave-nat-icmp-09

Fernando, 

Thank you for the comments. Please see my responses inline.

regards,
suresh

--- On Wed, 10/8/08, Fernando Gont <fernando <at> gont.com.ar> wrote:

> From: Fernando Gont <fernando <at> gont.com.ar>
> Subject: Re: [BEHAVE] [Int-area] WGLC: draft-ietf-behave-nat-icmp-09
> To: "Behave WG" <behave <at> ietf.org>, "'Internet Area'" <int-area <at> ietf.org>
> Cc: behave-chairs <at> tools.ietf.org
> Date: Wednesday, October 8, 2008, 12:15 PM
> At 05:31 p.m. 07/10/2008, Dan Wing wrote:
> 
> >    REQ-9: A NAT device MAY implement a policy control
> that prevents
> >    ICMP messages being generated toward certain
> interface(s).
> >    Implementation of such a policy control overrides
> the MUSTs in
> >    REQ-10.
> 
> Then.... shouldn't the requirements be
> "SHOULD"s rather than "MUST"s?
> 

[suresh] Essentially, the objective is not to dilute the MUST or SHOULD requirement on the NAT device, but

Re: [BEHAVE] WGLC: draft-ietf-behave-nat-icmp-09

Hello, Pyda,

Comments in-line...

> > >    REQ-9: A NAT device MAY implement a policy control
> > that prevents
> > >    ICMP messages being generated toward certain
> > interface(s).
> > >    Implementation of such a policy control overrides
> > the MUSTs in
> > >    REQ-10.
> >
> > Then.... shouldn't the requirements be
> > "SHOULD"s rather than "MUST"s?
>
>[suresh] Essentially, the objective is not to dilute the MUST or 
>SHOULD requirement on the NAT device, but to give the device admin 
>an override capability. So, if the admin chooses to enforce local 
>policies to override NAT operation, then the NAT device MAY enforce 
>the local policy control. Would the following revised wording work for you?
>
>Implementation of such a policy control overrides the MUSTs and 
>SHOULDs in REQ-10.

Any would work for me. I was just wondering if it was correct (from a 
the perspective of RFC2119) to include a MUST that could be overiden. 
That is, I was wondering if that means that the "requirements" should 
be a "SHOULD" rather than a "MUST".

> > >           5. Router Advertisement and Solicitations,

Re: [Int-area] WGLC: draft-ietf-behave-nat-icmp-09

--- On Wed, 10/8/08, Fernando Gont <fernando <at> gont.com.ar> wrote:

> From: Fernando Gont <fernando <at> gont.com.ar>
> Subject: Re: [BEHAVE] [Int-area] WGLC: draft-ietf-behave-nat-icmp-09
> To: srisuresh <at> yahoo.com, "Behave WG" <behave <at> ietf.org>, "'Internet Area'" <int-area <at> ietf.org>
> Cc: behave-chairs <at> tools.ietf.org
> Date: Wednesday, October 8, 2008, 5:37 PM
> Hello, Pyda,
> 
> Comments in-line...
> 
> 
> > > >    REQ-9: A NAT device MAY implement a
> policy control
> > > that prevents
> > > >    ICMP messages being generated toward
> certain
> > > interface(s).
> > > >    Implementation of such a policy control
> overrides
> > > the MUSTs in
> > > >    REQ-10.
> > >
> > > Then.... shouldn't the requirements be
> > > "SHOULD"s rather than
> "MUST"s?
> >
> >[suresh] Essentially, the objective is not to dilute
> the MUST or 

NTIA request for feedback on DNSSEC deployment at the root zone

Folks,

The National Telecommunications and Information Administration  
published a "Notice of Inquiry" entitled
"Enhancing the Security and Stability of the Internet's Domain  Name  
and Addressing System" in today's
Federal Register:

> SUMMARY: The Department of Commerce (Department) notes the increase in
> interest among government, technology experts and industry
> representatives regarding the deployment of Domain Name and Addressing
> System Security Extensions (DNSSEC) at the root zone level. The
> Department remains committed to preserving the security and stability
> of the DNS and is exploring the implementation of DNSSEC in the DNS
> hierarchy, including at the authoritative root zone level.  
> Accordingly,
> the Department is issuing this notice to invite comments regarding
> DNSSEC implementation at the root zone.

If you have an opinion on whether DNSSEC should or should not be  
deployed in the root zone, I urge you to make
that position known by submitting comments.   Comments are due on  
November 24, 2008.   Contact details are
included in the NOI.

The "html" version of the NOI is available at
          http://frwebgate5.access.gpo.gov/cgi-bin/waisgate.cgi? 
WAISdocID=559077321003+0+0+0&WAISaction=retrieve

Re: NTIA request for feedback on DNSSEC deployment at the root zone

>
> There are links to a number of process flow diagrams that may  
> interest you.

For easy accessibility of those links see:
http://www.ntia.doc.gov/DNS/DNSSEC.html

--Olaf

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