RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 30 June 2022 09:23 UTC

Return-Path: <vasilenko.eduard@huawei.com>
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 B7956C13CDAD for <ipv6@ietfa.amsl.com>; Thu, 30 Jun 2022 02:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4Xh86_rFe4s for <ipv6@ietfa.amsl.com>; Thu, 30 Jun 2022 02:23:03 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD61C13CDA7 for <ipv6@ietf.org>; Thu, 30 Jun 2022 02:23:02 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LYXsY1VT0z67wDW; Thu, 30 Jun 2022 17:22:09 +0800 (CST)
Received: from mscpeml500002.china.huawei.com (7.188.26.138) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 30 Jun 2022 11:22:57 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 30 Jun 2022 12:22:56 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.024; Thu, 30 Jun 2022 12:22:56 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
Thread-Topic: I-D Action: draft-ietf-6man-rfc6874bis-01.txt
Thread-Index: AQHYSu523qwOM60wqEqke88lJqADaazlGMyAgEBUkwCAQr4wcA==
Date: Thu, 30 Jun 2022 09:22:56 +0000
Message-ID: <f650c051650b4e5891b80dafb2dfaaaa@huawei.com>
References: <164938402532.17740.11717866110301931501@ietfa.amsl.com> <b1780128-2069-b32e-7ca5-86977c119f0c@gmail.com> <11d4e419-11a9-8768-abf2-1335e5f1c3d8@gmail.com>
In-Reply-To: <11d4e419-11a9-8768-abf2-1335e5f1c3d8@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.197.212]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/EaGBAOhnHYsSUcUFzfD-LHDBmDs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 30 Jun 2022 09:23:06 -0000

Hi Brian,
Just one small idea: does it make sense to request
"All applications claiming support for this document SHOULD choose one LLA zone as the default.
If the user would omit the zone for the literal request to fe80:: then the application SHOULD use the default zone".
It would greatly simplify life for many users because they have only one interface on the host - they would never need to investigate the name of the zone that is very OS-specific.

I do not like the request in RFC 4007:
index value zero at each scope SHOULD be reserved to mean "use the default zone"
IMHO: it is much better to omit the zone name completely to get access to the default zone.
People may not know that zone 0 has a special meaning.

Formally, what I have proposed does not contradict RFC 4007
Because the default zone could be omitted and could be 0 at the same time
(both would lead to the same default zone).

If you would say "No" to this request
Then please, repeat RFC 4007 that the default zone SHOULD be and SHOULD be "0".
Please, remind people of this fact.
Eduard
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Thursday, May 19, 2022 3:53 AM
To: ipv6@ietf.org
Subject: Re: I-D Action: draft-ietf-6man-rfc6874bis-01.txt

There's been no more discussion for several weeks. Can we move on to a WG Last Call?

Regards
    Brian Carpenter
On 08-Apr-22 14:29, Brian E Carpenter wrote:
> Hi,
> 
> This version reflects comments at the IETF and on the list.
> Change log:
> * Extended use cases (added Microsoft WSD)
> * Clarified relationship with RFC3986 language
> * Allow for legacy use of RFC6874 format
> * Augmented security considerations
> * Editorial and reference improvements
> 
> Note that some of the text about RFC3986 that Shang Ye suggested to 
> remove has been retained, but modified. Further comments about this, 
> or any other aspect, are very welcome.
> 
> Regards
>      Brian + co-authors
> 
> On 08-Apr-22 14:13, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>>
>>           Title           : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
>>           Authors         : Brian Carpenter
>>                             Stuart Cheshire
>>                             Robert M. Hinden
>> 	Filename        : draft-ietf-6man-rfc6874bis-01.txt
>> 	Pages           : 13
>> 	Date            : 2022-04-07
>>
>> Abstract:
>>      This document describes how the zone identifier of an IPv6 scoped
>>      address, defined as <zone_id> in the IPv6 Scoped Address Architecture
>>      (RFC 4007), can be represented in a literal IPv6 address and in a
>>      Uniform Resource Identifier that includes such a literal address.  It
>>      updates the URI Generic Syntax and Internationalized Resource
>>      Identifier specifications (RFC 3986, RFC 3987) accordingly, and
>>      obsoletes RFC 6874.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6874bis/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-6man-rfc6874bis-01.html
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc6874bis-01
>>
>>
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------