Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-deprecate-interdomain-asm

Loa Andersson <loa@pi.nu> Sun, 22 December 2019 15:38 UTC

Return-Path: <loa@pi.nu>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2080912012E; Sun, 22 Dec 2019 07:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 n5HZqcbe6Cfo; Sun, 22 Dec 2019 07:38:07 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075B11200E3; Sun, 22 Dec 2019 07:38:07 -0800 (PST)
Received: from [192.168.1.6] (unknown [119.94.175.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C088935DF54; Sun, 22 Dec 2019 16:38:03 +0100 (CET)
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mboned-deprecate-interdomain-asm@ietf.org" <draft-ietf-mboned-deprecate-interdomain-asm@ietf.org>
References: <1e2a9058-93b6-4b31-c4cc-2226a7e2c4e0@pi.nu> <3BB02AD5-DE0D-4676-BEC1-4702F0104477@jisc.ac.uk>
From: Loa Andersson <loa@pi.nu>
Message-ID: <11564704-563f-0d7a-aaca-30aff3a515d3@pi.nu>
Date: Sun, 22 Dec 2019 23:37:59 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <3BB02AD5-DE0D-4676-BEC1-4702F0104477@jisc.ac.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/99KEMCkmxYNvxLfSwT68fQ3xRi0>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mboned-deprecate-interdomain-asm
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Dec 2019 15:38:10 -0000

Tim,

Some snall comments, personal opinions and clarifications inline.

On 22/12/2019 17:54, Tim Chown wrote:
> Hi,
> 
> Many thanks for the review, comments in-line...
> 
>> On 22 Dec 2019, at 09:44, Loa Andersson <loa@pi.nu> wrote:
>>
>> <snip>
>>
>> Minor Issues:
>>
>> There is a document from the RFC Editor, RFC 7322 "RFC Style guide".
>> These guidelines should be followed, e.g. the "Requirement Language
>> should be moved into the body of the document, normally section 1.1.
> 
> Will do.  It seems RFC 7322 recommends a separate section 2 for this after the Introduction.

I think there is a mismatch between RFC 7332 and what the RFC Editor do.
If you look at RFC 8696, the latest published Standard Track RFC when I
write this. Intyroduction is section 1 and the 2119 language is
section 1.1.

> 
>> Someone (AD) should think about if the requirement language is needed in
>> this Informational document. A "MUST" is used when outlining what
>> draft-ietf-6man-rfc6434-bis does. but it is not really a requirement
>> from this document. I'm split about this and could go either way.
> 
> Perhaps put MUST in “”s in 4.2?

hmmmm - could be something we would want to do, but as I said I would 
take AD advice on this, especially if we intend to remove the 2119
language.

> 
>> Also the new template should be used for 2119 language.
>>
>> MLDv2 (or MLD) is not a well-know abbreviation and needs to be expanded.
> 
> Will do.  I think the RFC Editor would pick this up, but we can minimise their work :)
> 
>> IGMPv3 is well-known, but IGMPv3 is not. Beats me what is required,
>> but in such cases I always recommend expanding.

Copy and paste error on my side, what I intended to say was

IGMP is well-known, but IGMPv3 is not. Beats me what is required,
but in such cases I always recommend expanding.
Maybe you should do "IGMP version 3 (IGMPv3).
But I'd go with whatever you think we should do.
> 
> Not sure what you mean here.
> 
>> "
>> Nits:
>>
>> I wonder about this in section 3.1"
>>
>> "... has become widespread in common OSes for several years (Windows,
>> MacOS, Linux/Android)..."
>>
>> Should we say:
>>
>> "... has become widespread in common Operating Systems for several years
>> (Windows, MacOS, Linux/Android)..."
> 
> Can do.
> 
>> Other style issue:
>>
>> Sometimes IGMPv3 / MLDv2 is used
>>
>> At other places IGMP/MLD or IGMPv3/MLDv2, I think we should use one
>> or the other.
> 
> In some places, like 4.2, it is generic IGMP/MLD, but there are others where we should make it more specific, like 3.2.3.

Yes, that is right, but what I meant was that sometimes you put a space
on either side of the "/", sometimes not.

/Loa
> 
> Tim
> 
>> Nits tool has two issues, these are addressed in the Shepherd Write-up,
>> poimting out that updates
>>
>>
>> /Loa
>>
>>
>>
>>
>> -- 
>>
>>
>> Loa Andersson                        email: loa@pi.nu
>> Senior MPLS Expert
>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>>
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64