Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I wonder if anyone knows (or if there is an easy way to check, I doubt), if other STD documents have similar situations.

I mean, we define STDs, it takes long time to do so and meanwhile is still an RFC or even after a document is already an STD, there may be text sections that don’t reflect market reality, or some very specific exceptions (such as in this case /126-/127), that make sense (or not), but in any case, the STD is not being modified again and again.

I’m sure this happens in any kind of documents in other business and life fields, for example, there may be generic laws, and afterwards, the generic law is not modified for many many many years, but “exception rules” are created for those laws.

So, are we spending too much time in this and is not really necessary?

Can we live with the actual text with has been in the market, and working well, for “x” years?

Can we make too many (or few very important) changes in an RFC in the way to STD, or we need first to have those changes in an RFC for “x” years and “n” verified implementations, before we move to STD? If the answer is no, is the balance between living with the current text but moving to STD a better option than waiting for “x” years again?

Regards,
Jordi
 

-----Mensaje original-----
De: ietf <ietf-bounces@xxxxxxxx> en nombre de Gert Doering <gert@xxxxxxxxx>
Responder a: <gert@xxxxxxxxx>
Fecha: viernes, 24 de febrero de 2017, 8:59
Para: Pierre Pfister <pierre.pfister@xxxxxxxx>
CC: IPv6 Operations <v6ops@xxxxxxxx>, Mark Smith <markzzzsmith@xxxxxxxxx>, IETF <ietf@xxxxxxxx>
Asunto: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

    Hi,
    
    On Thu, Feb 23, 2017 at 11:43:52PM +0100, Pierre Pfister wrote:
    > >>>                                          However, the Interface ID of
    > >>>   all unicast addresses, except those that start with the binary value
    > >>>   000, is required to be 64 bits long.
    > >> 
    > > 
    > > The thing is this is not new text, it has been in RFC4291 for 11
    > > years. c.f., 2.5.1.
    > 
    > And during those 11 years. Nobody implemented this rule specific to ::/3.
    
    The point is not "specific rule for ::/3".  The point is that this is a
    explicit rule for all that is *not* ::/3, with an exception(!) for ::/3.
    
    ... and still there are other RFCs that permit /126 and /127, so this
    definitely needs rewording to match current reality.
    
    Gert Doering
            -- NetMaster
    -- 
    have you enabled IPv6 on something today...?
    
    SpaceNet AG                        Vorstand: Sebastian v. Bomhard
    Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]