Re: Adoption Call for <draft-templin-6man-omni-interface>

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 08 August 2020 03:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3963A0BC1 for <ipv6@ietfa.amsl.com>; Fri, 7 Aug 2020 20:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ0aLykdq1XF for <ipv6@ietfa.amsl.com>; Fri, 7 Aug 2020 20:25:04 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C563A0BBE for <ipv6@ietf.org>; Fri, 7 Aug 2020 20:25:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 90651389CF for <ipv6@ietf.org>; Fri, 7 Aug 2020 23:04:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a8VShduCAqoE for <ipv6@ietf.org>; Fri, 7 Aug 2020 23:04:15 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C837389CE for <ipv6@ietf.org>; Fri, 7 Aug 2020 23:04:14 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BAAC642 for <ipv6@ietf.org>; Fri, 7 Aug 2020 23:24:55 -0400 (EDT)
Subject: Re: Adoption Call for <draft-templin-6man-omni-interface>
To: ipv6@ietf.org
References: <0540F46E-2E31-4E85-BC48-05C351A86113@gmail.com>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <8ab96440-f50b-b93a-d21f-05ce09160f7b@sandelman.ca>
Date: Fri, 07 Aug 2020 23:24:55 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <0540F46E-2E31-4E85-BC48-05C351A86113@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Xv9IGt-KJKMbT-rfaXqBPzOUCY8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2020 03:25:06 -0000

Hi, I read draft-templin-6man-omni-interface-27. 

The document is very complete (-27!), and 6man should have adopted it 
awhile ago.   It being very complete is an issue for me.  This work has 
it's own external design team, and I guess the plan is that all of those 
people will form the core of an IETF/6man design team.  But, actually I 
wonder if it shouldn't have it's own WG.

I don't think I would have time to join this DT.
 

Overview: how does this document interact with the RAW WG, which seems 
also to have not adopted any documents yet. 

For instance, this document seems like it might overlap somewhere: 

    draft-maeurer-raw-ldacs-04 

    L-band Digital Aeronautical Communications System (LDACS) 

 

I found the Introduction to be TLA dense, and I would prefer that this 
level
of detail be deferred a section or two in order to focus on a short 
version
of the problem statement, and a less intensive introduction. 

 

I would like the terms 

    OMNI Link-Local Address (LLA)        -> OLLA 

    OMNI Unique-Local Address (ULA)      -> OULA 

 

It appears that the term "OMNI LLA" and "OMNI ULA" are in fact used. 

 

I would sections 2(Terminology) with 3(Requirements/BCP14), making it 
clear that MUST/SHOULD/etc. are terminology. 

 

Although you've just told me what all the terms are in the Terminology, 
I haven't yet passed the pop quiz, so it would be a kindness if in 
section 5, you expanded the terms.  Maybe not just the first time for 
the less obvious ones.
 

Maybe figure 1 (or a simplified version), could go into the 
Introduction?
 

I'm surprised that there is any discussion of IPv4 in section 5. 

I'd have thought some v4-over-v6/IPv4-as-a-Service technology would be 
used.
The first I read of this extension header between inner and outer 
IP(v6?) header is in section 5, about PMTU.  I feel that perhaps this 
section is too early in the document? 


Why 640 bytes? 


I think you should have some text WRT interactions with PLPMTU. 

    ICAO Doc 9776 (VDL Mode 2 Technical Manual) <- should be a 
reference.
 

Can an MNP be longer than 56bits?  If it was, would the resulting LLA 

be longer than 64?  It seems so, right? 

 

    Since the prefix 0000::/8 is "Reserved by the IETF" [RFC4291], no 

    MNPs can be allocated from that block ensuring that there is no 

    possibility for overlap between the above OMNI LLA constructs.~ 

 

I'm not concerned here, because the IETF *could* do something with that 
block.  But, more generally, I have no idea in this spot of reading the 
document what LLAs are going to be used for, so the discussion of them 
makes no sense.  (Having finished the document, I'm still a bit puzzled)
 

    This document updates [RFC4193] by reserving 

    the ULA prefix fc80::/10 for mapping OMNI LLAs to routable OMNI 
ULAs.
 

that's part of aka ULA-Central, right? 

It seems like this might be better to repurpose site-local fec0::/10!!! 

 

I skipped the ND sub-options for now. 

It seems that users of VRRP is very much IPv4-think, and that an IPv6 
should
simply use a LL-anycast address. 

 

   "public domain implementations" --> "open source implementations" 

(I'm pretty sure they code has a copyright, even if it's BSD-2clause)