Subject: <draft-ietf-6man-rfc2460bis-12.txt>

From: Bob Hinden <[email-masked]>
Date: Tue, 16 May 2017 10:37:14 -0700

Hi,

I published the -12 version of 6man working group draft of rfc2460bis.  Links below.

The only changes in this draft was:

     o  Editorial changes (mainly remove old duplicate paragraph).

A diff from the -11 version can be found at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-12

Please review the changes.

This is part of the project to move the core IPv6 specifications to Internet Standard.

Thanks,
Bob

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Maintenance of the IETF.
> 
>        Title           : Internet Protocol, Version 6 (IPv6) Specification
>        Authors         : Stephen E. Deering <>
>                          Robert M. Hinden
> 	Filename        : draft-ietf-6man-rfc2460bis-12.txt
> 	Pages           : 45
> 	Date            : 2017-05-16
> 
> Abstract:
>   This document specifies version 6 of the Internet Protocol (IPv6).
>   It obsoletes RFC2460
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-12
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc2460bis-12
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-12
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 May 2017 02:32:15 +0200

Hello, Bob,

> This is part of the project to move the core IPv6 specifications to Internet Standard.

I just checked the ballot for this document. Mirja has a point here. in
that rfc2460bis uses a different language than RFC6564. In
retrospective, it would seem to me that rfc2460bis has the correct
phrasing, and that RFC6564 is kind of using wrong RFC2119 language: it
states a requirement as a MUST, but then gives reasons for not complying
with such MUST -- that is, that's actually a SHOULD ;-)

Not sure what would be the correct way forward -- maybe noting this in
rfc2460bis and formally updating RFC6564? Just continue "as is" and fill
an errata for RFC6564?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Bob Hinden <[email-masked]>
Date: Tue, 16 May 2017 17:59:15 -0700

Fernando,

> On May 16, 2017, at 5:32 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Bob,
> 

Right, I explained the situation in my email to Mirja about her Discuss on May 9.

> rfc2460bis and formally updating RFC6564? Just continue "as is" and fill

As you point out, rfc2460bis is correct.

I don’t see much point in filing an errata on RFC6564.  While it should have said SHOULD, the “unless” clause makes it’s intent clear.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 May 2017 13:22:24 +1200

> I don’t see much point in filing an errata on RFC6564.  While it should have said SHOULD, the “unless” clause makes it’s intent clear.

Since RFC 2119 does not explicitly forbid the "MUST NOT unless" construct, I'm not even sure it's an error. It's a great deal clearer than some prohibitions:
http://wtop.com/wp-content/uploads/2015/06/idaho_parking_ari_cropped2.jpg

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 17 May 2017 09:59:15 +0200

>> I don’t see much point in filing an errata on RFC6564.  While it should have said SHOULD, the “unless” clause makes it’s intent clear.

In normal prose, I'd agree. But with the RFC2119 where "MUST"/"MUST NOT"
are employed to specify requirements that, if not met, would cause
serious interperability problems.. I'm not sure how one would interpret
such statement.

For instance, if defining new EHs MUST NOT be done (because of the
consequences) then, if you have a good reason to do so, you'd still be
paying for the consequences.  (if you still break stuff, then it should
have been a "MUST" with no "unless". If you don't break stuff, then it
should have been a "SHOULD").

> Since RFC 2119 does not explicitly forbid the "MUST NOT unless" construct, I'm not even sure it's an error. 

Strictly speaking, I might agree. However, my mental model is that only
SHOULDs have such conditionals.

> It's a great deal clearer than some prohibitions:

:-))