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

[Fred Baker <[e-mail]>]

You may be correct. My understanding of the author's intention/usage is that, like anyone that purchases equipment and software, they include in their RFP/RFQ references that they want a vendor to say they support. They can use this in that context. The IETF is not recommending it, but a purchasing agent might require it for products used in their network.

There is an issue with posting as an internet draft and leaving it hanging in space. We claim that they disappear, and we actually kinda-sorta make it look that way. We also state, in the I-D boilerplate, that folks shouldn't reference it. It becomes referencable when it gets an RFC number. Now, there's what we say and what we do, I understand, but we do try to pretend that they are the same thing.

The Independent Stream, whether or not it has been called that (it was once called "I sent something to Jon"), has been with use since the RFC series came into existence. It publishes April Fool's RFCs, poetry (RFC 968), white papers, and a variety of other things. And yes, companies have published what are otherwise proprietary protocols or descriptions of proprietary technology. We didn't call it the "Independent Stream" in 1994, we simply called it "publishing as INFORMATIONAL" or "...EXPERIMENTAL", but RFC 1701/2 (GRE) was pretty much that; we knew how to send IP/IP and a few other things, but we needed a way to send AppleTalk/IP, SNA/IP, and etc. The authors designed and published a way to do it, which allowed other companies to also use it at their discretion. Six years later, it was updated and published as a Proposed Standard, and there has been further work. Think of RFC 1701/2 as a pair of "Internet Drafts", if you will, that had a longer lifetime. When we had experience with it, we collectively decided we wanted an actual consensus document. And the rest is history.

My point being that using the Independent Stream for this kind of thing isn't exactly new. It's not something I would recommend to anyone, but it is a tool that is available.
 
> On Mar 5, 2017, at 4:29 AM, Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> 
> Le 04/03/2017 à 21:12, Fred Baker a écrit :
>> 
>>> On Mar 4, 2017, at 5:01 AM, Alexandre Petrescu
>>> <[e-mail]> wrote:
>>> 
>>>> RFC 7849 is not a product of v6ops.
>>> 
>>> Seems so... although I remember there was some discussion here
>>> about it.
>> 
>> It was introduced in v6ops and discussed. It went through several
>> revisions, including being adopted by the working group and then
>> dropped due to dissent.
>> 
>> -
>> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-reqs-rfc3316update
>> 
>> 
>> 
> -
> https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements
>> -
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile
>> 
>> 
>> 
> I think the fairest thing to say is that there were three separate
>> consensuses in the discussion: those that supported it (the authors,
>> representing a number of 3GPP networks), those that didn't (a set of
>> people who also worked in 3GPP), and those that wished we would talk
>> about something else. The chairs (Joel and I) eventually suggested
>> to the authors that they publish it in the Independent Stream, which
>> they did.
> 
> Hi Fred,
> 
> I think that course of action looks reasonable.  I think often RFCs get
> this path of independent stream.
> 
> However, I would like to raise a strong doubt about making RFC at IETF
> when IETF does not want it to be an RFC.
> 
> I think it is a waste of time from both IETF process participants, and
> also from operators redirecting me to that RFC while also telling me it
> has little value other than simply having "IETF" and "3GPP" in its front
> page.
> 
> If it is an individual ambition from authors and Sponsor, then it could
> stay at Internet Draft level - experience shows now Internet Drafts live
> long time even though they are 'expired'.  Or it could be published as
> other means.
> 
> Alex
> 
>> 
>> 
>>