Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2011 14:11:14 +1300

Hi,

I think I'm going to make myself unpopular.

Reading this document as a proposed standard, I think it will confuse the reader.
I think that what we actually need is a 100% replacement of RFC 3484, that
can be read on its own.

(We've been here before - the same argument is why we ended up doing 3697bis.)

If that is not done, I would suggest reorganising the text so that (after
a short Introduction) the reader finds:

- firstly, a complete but concise statement of the normative changes made to 3484
  (such as section 2.1.5, and the new rules 5.1 and 9)

- secondly, the explanations (such as sections 2.1.1-2.1.4).

An implementer would only need to read the first part.

Trivia:

Needs a header: Updates: 3484 (if approved)

> 4.  IANA Considerations
> 
>    Address type number for the policy table may have to be assigned by
>    IANA.

You can't say "may", you have to tell IANA exactly what to do in which registry.

   Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Sun, 13 Nov 2011 17:19:13 +0900

Brian,

thank you for your comments.

> An implementer would only need to read the first part.

This document had started as an update, because there was not so many
things to update at first.

As the document gets older, it got a bit bigger than I had expected.

So, which of update or replace do you prefer ?

> You can't say "may", you have to tell IANA exactly what to do in which registry.

Thanks !

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2011 11:47:56 +1300

> So, which of update or replace do you prefer ?

Hmm. If we want to go quickly, an update that makes it easy for
the implementer to find the changes is better.

Regards
   Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Nov 2011 11:48:47 +0000

I have read and reviewed -05.

The document is a good start, but I have some issues with it currently.   

Summary of substantial technical issues:

1) In the updated prefix policy table, the order of rows is ok, but the precedence
values are a major problem that would make it difficult if not impossible for us
to implement/deploy the current draft. Please change to preserve the precedence
values to be the same as in RFC 3484 except where a change is actually required.
For example, ::1/128 should remain 50. Teredo should be 5, which is what has 
been deployed for many years now.   The operational issues center around ways
to configure nodes with additional rules.   Ones already exist in some implementations
and changing the values means that you can't push a rule out to a host unless you
know it's a new vs old host.   Avoiding gratuitous changes means you can have 
one new-row pushed out to all hosts.   I personally consider this a showstopper 
for the draft.

2) The current Rule 5.1 text 
"Rule 5.1: Use an address assigned by the selected next-hop."
is problematic for two reasons:
   i) Next-hops don't assign addresses, they advertise prefixes. Addresses are 
      assigned by the hosts themselves (in SLAAC) or by DHCP servers.
      It should say something like "Prefer addresses in a prefix advertised by the next-hop"
   ii) nowhere does the doc have text about whether a host must remember 
     who it got an on-link prefix from. RFC 4861 section 5 doesn't say it does.
     RFC 4191 section 3 doesn't either. And this document has no section 
     that's similar to either one. Note that 4191 section 3 defines some as 
     being optional. Is this one optional or required?    I don't have a concern
     either way, my concern is that the document doesn't say anything like
     what it ought to cover in order to enable this rule.

Summary of editorial issues:

1) As Brian pointed out one instance of, many places in the doc say what _could_ 
be done.  A standards track document needs to instead specify what _is_ done.

2) Several informative references (that are drafts not RFCs) are used in text in 
normative ways.   Rather than making them be normative references, the text
should be updated so that the use is clearly informative.

3) A number of grammar issues.  Parts of Appendix B are rather hard to read 
for instance.  Perhaps it can just be deleted.

Also I prefer the Updates (not Obsoletes) option, where the document 
specifies the deltas.   This is the current approach in the doc.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Monday, November 14, 2011 6:48 AM
> To: Arifumi Matsumoto
> Cc: 6man
> Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
> 
> Hmm. If we want to go quickly, an update that makes it easy for the
> implementer to find the changes is better.
> 
> Regards
>    Brian
> 
> >> I think that what we actually need is a 100% replacement of RFC 3484,
> >> that can be read on its own.
> >>
> >> If that is not done, I would suggest reorganising the text so that
> >> (after a short Introduction) the reader finds:
> >>
> >> - firstly, a complete but concise statement of the normative changes
> >> made to 3484  (such as section 2.1.5, and the new rules 5.1 and 9)
> >>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Nov 2011 11:50:18 +0000

A marked-up version with my full comments in context can be found at
http://research.microsoft.com/~dthaler/draft-ietf-6man-rfc3484-revise-05.pdf

-Dave

> From: Dave Thaler
> Sent: Wednesday, November 16, 2011 7:49 PM
> To: 6man
> Cc: 'Brian E Carpenter'; Arifumi Matsumoto
> Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
> 
> 1) In the updated prefix policy table, the order of rows is ok, but the
> precedence values are a major problem that would make it difficult if not
> impossible for us to implement/deploy the current draft. Please change to
> preserve the precedence values to be the same as in RFC 3484 except where
> a change is actually required.
> 1) As Brian pointed out one instance of, many places in the doc say what
> _could_ be done.  A standards track document needs to instead specify what
> _is_ done.
> 
> > >> Reading this document as a proposed standard, I think it will confuse
> the
> > reader.
> > >> (We've been here before - the same argument is why we ended up
> doing
> > >> 3697bis.)
> > >>