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

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Mar 2011 14:21:35 -0500

John Leslie <[email-masked]> writes:

> Pekka Savola <[email-masked]> wrote:
> > On Mon, 17 Jan 2011, Thomas Narten wrote:
> >>>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
> >
> > I have reviewed this document.
> > 
> > The most important omission is that RFC4294 changelog is not up-to-date.
> > This gives a good overview on what has changed and it needs to convey
> > accurate information.

>    Comparing bis-07 to RFC 4294, the number of changes begins to boggle...

>    I strongly concur with Pekka that this document needs a single
> "changes from 4294" section.

In the works.. :-)

>    And, seeing as 4294 will be five years old by the time 4294-bis is
> published, I'd suggest adding to that section a note on where to look
> for "pending" changes over the next five years. ;^)

:-( ...

>    (BTW, I remain confused on what happened to 5.2.1 of 4294 "Managed
> Address Configuration". Hopefully that will become clearer with a
> single "changes since 4294" section.)

It got yanked. We do not have consensus on what to do with these
flags. I think that is broken, but I believe the proper way to fix
this is via a standalone document that updates the relevant specs.

It is not appropriate to fix that in node requirements.

I've added the following to the changes section:

    16. Removed discussion of "Managed" and "Other" flags in
    RAs. There is no consensus at present on how to process these
    flags and discussion of their semantics was removed in the most
    recent update of Stateless Address Autoconfiguration (RFC 4862).

>    (I suppose this means I volunteer to help draft such a section, but
> to tell truth I'm not sure where to start!)

heh!

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 10 Mar 2011 23:04:54 -0500

> I have reviewed this document.

Thanks agin!

> This gives a good overview on what has changed and it needs to convey

ACK.

I've just posted a new version. Have a look to see the changes.

> At the same time, I'd also add (or check from WG) if some of the RFCs
> not listed should be included.

We've done multiple passes on trying to include all relevant
RFCs. Seems to be a never-ending task...

> Some requirement levels have also changed, and explicit support from
> WG would be good on these.  With an updated RFC4294 changelog, rough
> consensus on the result could be evaluated.

OK. But to be clear, the changes in this document have been discussed
on the list and IMO do have consensus. I.e., they are not "surprises".

> I think a brief WGLC should be warranted after document update.

OK (if we can get more reviewers!)

> The document should be IETF last called.

No objection.

> WG should explicitly request feedback from at least IPSECME WG.

IPsecME has seen and reviewed text. Indeed, some IPsecME members
helped with getting the text right. I also presented the text at the
saag meeting in Maastricht

> substantial
> -----------

> General:

> Section 21 describes Changes from RFC 4294.  This is not up-to-date. 
> Specifically, at least S 17-20 describe changes between draft versions that
> are not incorporated in S 21.  As "changes between drafts" sections are
> removed upon publication, it is important that the changes from the previous
> RFC are complete.  The updated RFC references are of medium importance
> (there are significant changes e.g. in the requirements imposed by ICMP
> specification versons), but changes in requirement level seem like a high
> importance issue. As such the former could be addressed with a short
> list.

I took a stab at this, but I'm not sure I got all the major
changes. In particular, there were a couple of revs of the ID before
we started adding changes between versions.

> This is a very important section for a document like this as just by
> looking at it you should be able to see the major new requirements
> or changes in requirements.  Therefore, updating this should be the
> first priority.  Then I would suggest another Last Call, just to
> make sure there's rough consensus on these higher level bits.

fine with me.

> Specific not in text:
> ---------------------

> I think this document should also discuss APIs we have defined and that
> relate to the protocols described in the document.  A separate section
> should be added on this.

I added a section on APIs. I made them all FYIs. I agree with the
comments others have made on the list that we can't mandate them.

> RFC4191 (Default Router Preferences and More-Specific Routes) should
> be discussed.  Is this a MAY?  Quite a few host implementations
> already support it.

I added it as a MAY. I don't think its widely enough implmented or
used (?) to say this is even a SHOULD.

> In the context of autoconfiguration, RFC5453 (Reserved IPv6
> Interface Identifiers) should probably be discussed. My quick
> (re-)read of it seems to say that every host should avoid the
> designated IIDs. Is host support needed for this?

I added a reference to 5453 to the section on temporary addresses.

> Should Node Information Queries be mentioned (RFC4620)?  It would be
> a MAY.  I'm fine with leaving it out.

I think not. AFAIK, its not widely used.

> S 5.8.2 could refer to RFC4429 (Optimistic DAD) with a MAY support.

I added a paragraph on this, but made it clear this is not something
that general purpose nodes need to do at this time.

> The document is silent on Flow Label (as Brian mentioned).  Rather than
> silence, I might be tempted to say something at least from the current
> perspective.  The key point here is, "are hosts expected to randomize or
> otherwise by default set a flow label"?

I'll defer to the list for guidance. That said, the general position
being taken for this document is not to update other specs, but to
refer to them. Given the Flow Label spec is under review, I don't
think we should say much. 

> Specific on text:
> -----------------

> S 5.2 no longer requires support for DAD but this is actually done 
> in S 5.8.2.  A pointer might be helpful (though not necessary).

I think what I did was consolidate text that was (previously) in two
sections in RFC 4294.

> Text on redirects is also new, but probably not very controversial.

It was taken from the mailing list...

> S 5.5.1 does not make any (uppercase) recommendation on PMTUD like the
> previous version did, just quoting RFC2460.

That was intentional.  I don't see why we need to say you MUST do
2460, and then go and say you MUST/SHOULD do things that are required
in 2460 already. That seems redudent to me, and raises the question of
why we do that for some, but not other pieces. AFAICT, most everyone
implements PMTUD. So I don't think we need to call out any part of RFC
1981 specifically.

> line with: "Path MTU Discovery [RFC1981] SHOULD be Supported. From
> [RFC2460]:"

done

> S 5.8.3 has watered down the privacy addresses text:

>     In such situations, RFC4941 SHOULD be implemented.  In other cases,
>     such as with dedicated servers in a data center, RFC4941 provides
>     limited or no benefit.

> .. this is not acceptable.  Per previous RFC, we should say:

>     RFC4941 SHOULD be supported.

I strongly disagree, and there was a thread about this. I have seen
cases where people just assume that 4941 should be supported by all
nodes, including servers (not clients) in data centers. There is no
need to implement 4941 on server-only systems.

Please review the thread at
http://www.ietf.org/mail-archive/web/ipv6/current/msg10468.html and if
you have further comments, speak up. But it was an explicit goal to
not just say "SHOULD" with not context/direction, as RFC 4294 does.

> We could also add (or make specific recommendations):
>     This document does not make a generic recommendation on the default
>     behaviour.

> I note that previous version of the doc also suggested privacy be configurable
> on per-connection basis, etc. -- this text has been removed now. (I did not
> dig deeper whether it has been incorporated in RFC4941 revisions
> etc.)

Discussed on list (a very long while back). The suggestion to do
per-connection overrides and all was deemed as going too far.

> In S 5.9,
>     A reference should be added (MAY support) to RFC 5790, 
> "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and
> Multicast Listener Discovery Version 2 (MLDv2) Protocols"

Actually, I may need some help with this.

If 5790 is enough, and omits functionality that most nodes don't need,
we should recommend its usage.

We should provide clear guidance on when it makes sense to recommend
one over the other.

> In S 7.3:
>     Implementations SHOULD implement the DNS RA option [RFC6106].

> .. is this too strong?  DHCP is (only) a conditional SHOULD. I'm OK with
> this as it is, but I would also be fine with a MAY.

This was discussed on the list (a little). I could go either way.
Curent text is a SHOULD (see Section 7.3 of the draft).

> In S 10, Certain Mobile IP-specific SHOULDs have been downgraded to
> a general MAY.  I'm fine with this but I would have been OK with
> retaining those specific SHOULDs.

Long list discussion. I think the feeling about MIPv6 has changed. It
has clearly not been deployed and there may be better alternatives
now.  Hence, a MAY.

> In S 11, IPsec and IKE have been downgraded to a SHOULD. I'm fine with this.
> (None of the changes I've mentioned are listed in the changelog.)

Added to changelog. And discussed in all the right places, (6man,
saag, ipsecme).

> editorial:
> ----------
>     -  Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
>        [RFC2529]

> ... even as an example, this is a bad one. It is not used and there exists
> probably about one implementation.  I suggest replacing this with RFC4213
> (an existing reference).

Done.

> 5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710

> .. take out the RFC number from the title as you're actually addressing two
> different MLD versions in this subsection.

Done.

>     The following two MIBs SHOULD be supported by nodes that support an
>     SNMP agent.

> .. s/MIBs/MIB modules/ :P

Done.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 11 Mar 2011 06:56:41 -0800

One small clarification from the chairs to avoid any confusion.

>> The document should be IETF last called.

All documents the 6man w.g. advances to the IESG are IETF last called.  It's not an optional step.

Bob & Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Mar 2011 15:51:03 +0200 (EET)

> on the list and IMO do have consensus. I.e., they are not "surprises".

Yes, I don't doubt they've been mentioned, but given the long time 
cycle and that a lot of participants do not have time to read all 
the mails very closely, strong consensus can be best built by 
iteration. (But it can also lead to iteration cycles and hashing the 
same issues over and over again, of course)

>> The document should be IETF last called.

Wrt. to Bob's comment, I was just pointing out that Informational 
documents do not (by IETF procedures) require an IETF Last Call. It's 
good that 6MAN documents have set a higher bar :-)

> saag meeting in Maastricht

Great to hear, maybe this is a non-issue then!

> comments others have made on the list that we can't mandate them.

Works for me.

> not just say "SHOULD" with not context/direction, as RFC 4294 does.

I should have articulated my objection more clearly. The issue stems 
from the word "implemented".  I totally agree that it's a bad idea to 
turn on 4941 on server nodes.  But because it's usually difficult to 
distinguish purely client and server implementations, in most cases 
4941 should be implemented -- the big question is really whether to 
turn it on or off.

> We should provide clear guidance on when it makes sense to recommend

Hitoshi Aseada (author) made some suggestions on this on the list on 
Feb 21-22.  IMHO, 5790 seems enough and only omits functionality that 
the most nodes don't need (but I also don't see a pressing need for 
existing implementations to take out these bits).

....

A few editorial bugs in the latest version:

- the added text on more-specific routes (S 5.3) mistakenly points to
   rfc5942.

- running " in the added rfc4941 text in S 5.9.3

- there's some overlap in the changelog section, at least rfc5952 and
   rfc5722 are mentioned twice. (strange to see both numbered and
   non-numbered entries there as well.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings