Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-07.txt>

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Jan 2011 17:12:45 +1300

I would be happy to see this published as-is, but I did notice
a few points.

I think the Introduction needs a general warning something like:

 This document reflects the state of IPv6 standards at a particular
 moment. Subsequent standards work and operational experience may
 require changes to the recommendations in this document.

Also in the Introduction:

>    As it is not always possible for an implementer to know the exact
>    usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
>    that they should adhere to Jon Postel's Robustness Principle:
> 
>    Be conservative in what you do, be liberal in what you accept from
>    others [RFC0793].

Note that this is also present in RFC 1958, by which time
Jon had reformulated it slightly as:

> Be strict when sending and tolerant when receiving.

In 4.  Sub-IP Layer

>    In addition to traditional physical link-layers, it is also possible
>    to tunnel IPv6 over other protocols.  Examples include:

Should we mention that basic v6/v4 tunnels are specified in [RFC4213]?

And the examples

>    -  Teredo: Tunneling IPv6 over UDP through Network Address
>       Translations (NATs) [RFC4380]
>    -  Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
>       [RFC2529]

may not be so well chosen. Teredo is not loved by operators, and
RFC 2529 is essentially unused today. Maybe 6rd (RFC 5969)and
hub-and-spoke (RFC 5571) would be better examples.

Two topics are not mentioned.

1. The flow label and RFC 3697. I think that is probably wise until
we produce 3697bis.

2. DNSSEC. I don't recall whether we discussed that. If we did,
I'm sorry to raise it again. However, I suspect we will get pushback
in security review if it is not mentioned.

Nit: there should be a Replaces: 4294 header.

   Brian

---

From: <[email-masked]>
Date: Sun, 16 Jan 2011 20:25:57 +0000

Brian,

I did not see any comments on this, but in general I agree with your points below.

Comments in-line

-----Original Message-----
>  require changes to the recommendations in this document.

This makes sense.

> > Be strict when sending and tolerant when receiving.

I always thought the 793 text was a bit more poetic, but I think either is fine.

> hub-and-spoke (RFC 5571) would be better examples.

Including 4213 makes sense, and I don't oppose dropping 2529.  Terado support
is a judgement call, IMO.

> 1. The flow label and RFC 3697. I think that is probably wise until

I agree.

> in security review if it is not mentioned.

Do we (6man) have any opinion here?

> Nit: there should be a Replaces: 4294 header.

Agree.

John

---

From: Thomas Narten <[email-masked]>
Date: Mon, 17 Jan 2011 14:32:30 -0500

6man:

The LC on this document supposedly ended on Jan 6, but it's pretty
obvious that there haven't been enough reviews yet to convince me that
the document has received sufficient review to move forward.

Now that we're past the holiday seasons,  how about a few more
reviews?

Thanks!

Thomas

> All,

> This message starts a 6MAN Working Group Last Call on advancing:

> 	Title           : IPv6 Node Requirements RFC 4294-bis
> 	Author(s)       : E. Jankiewicz, et al.
> 	Filename        : draft-ietf-6man-node-req-bis-07.txt
> 	Pages           : 26
> 	Date            : 2010-12-16
> 	
>         http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07

> as an Informational RFC.  Substantive comments and statements of
>  support for advancing this document should be directed to the
>  mailing list.  Editorial suggestions can be sent to the authors.
>  This last call will end on January 6, 2011.

> Note, while not indicated in the draft the intent for this document
>  is to obsolete RFC4294. The next version will show this more
>  clearly.

> Regards,
> Bob Hinden & Brian Haberman
> 6MAN Chairs

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------