Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP

[Alexandre Petrescu <[e-mail]>]

Le 05/03/2017 à 20:07, Brian E Carpenter a écrit :
[...]
>>> "The consensus-based IETF description of IPv6 functionality for
>>> cellular hosts is described in RFC 7066. ... This document is
>>> not an Internet Standards Track specification; it is published
>>> for informational purposes.
>>
>> As such, it should not have an RFC number.
>
> The IETF does not own the RFC series. See
> https://www.rfc-editor.org/about/independent/ and RFCs 5741, 5742,
> 6548.

I will look at that.

Until then:

The RFC-Editor MUST NOT publish documents which are _against_
technically valid oppinion of professionals of the technology,
represented in the WG.

When the RFC-Editor carefully Edits text written by the technically
inclined, the technically inclined does not dare to correct them back,
right?  In return, the RFC-Editor should not publish technical oppinion
which is against technical oppinion of a particular WG.  They dont have
the appropriate skillset to qualify that.

I could agree they could publish something that is neutral, like an
April Fool's RFC.  But it is obvious this document is far from neutral:
it even lists requirements(!)

How could someone publish something that says "deployments require X"
when people doing these deployments say "deployments require Y"?

Also, I wonder whether Authors of the document are conscious that that
document has no value whatsoever?  If it were so, the document would not
even be invoked, in any discussion... so why publishing it at all?  But
I think the Authors believe this RFC has some value, they are using it
somehow, otherwise they would not agree publishing it.

Who can gain from this?  How is the document used?  Does the RFC-Editor
have some explanation about that?

(and no, I will not write a document about what may appear a destructing
activity; I prefer continue working in a constructive way towards
deployment of DHCPv6-PD in 3GPP networks - the "target";
I just hope the RFC Editor does not make that harder :-)

Alex

>
> Brian (member of the ISEB, https://www.rfc-editor.org/about/ISEB/ )
>
>>
>> There are many I-Ds out there without RFC numbers - they are also
>> for informational purposes.
>>
>>> This is a contribution to the RFC Series, independently of any
>>> other RFC stream.  The RFC Editor has chosen to publish this
>>> document at its discretion and makes no statement about its
>>> value for implementation or deployment.  Documents approved for
>>> publication by the RFC Editor are not a candidate for any level
>>> of Internet Standard..."
>>
>> As such, it should not have an RFC number.
>>
>> Alex
>>
>>>
>>> ?
>>>
>>> Brian
>>>
>>
>
>