Re: [Editorial Errata Reported] RFC5952 (4986)

[Fernando Gont <[e-mail]>]

On 04/03/2017 12:09 AM, Doug Barton wrote:
[....]
>>
>> So should Section 4.2.2 stand, on not shortening one 16-bit field of
>> zeros?
>> https://tools.ietf.org/html/rfc5952#section-4.2.2
> 
> I wasn't involved in the 5952 discussion, so it would be hard for me to
> comment. On principle though I would say no, because ...
> 
>> The rationale for that section given in earlier versions of the draft up
>> until -04 says ""::" should not be used to shorten just one 16 bit 0
>> field for it would tend to mislead that there are more than one 16 bit
>> field that is shortened”, which seems a bit weak, and at odds with
>> RFC4291 as above?
>> https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-04#section-4.2.2
>>
> 
> ... I find it sad that A) people could think that this is a problem, and
> B) that people who are confused about how many 16 bit fields make up an
> IPv6 address could possibly get more confused by how many fields are
> being replaced by all-zeros. (Is 1:2:3:4:5:6::8 really ambiguous?
> Seriously?)

I agree with you on this one. That said, RFC5952 did update RFC4291.



> So if updating 4.2.2 of 5952 will make things more clear for people, it
> should probably be done.

RFC5952 updated RFC4291 in this respect. Having another document update
RFC5952 on this respect would be a kind of spaghetti kind of hard to parse.

At this point, and given the recent discussion regarding rfc4291bis, I'm
wondering if it might make sense to publish rfc4291bis such that lots of
things get cleared up, and move/postpone the "rfc4291bis to IS" to a
later stage? (me thinking out loud)

Thanks!

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