IETF Logo Mail Archive

Re: [v6ops] RFC8174 keywords -- Re: Some feedbacks - RE: I-D Action: draft-ietf-v6ops-hbh-01.txt

Xipengxiao <xipengxiao@huawei.com> Tue, 19 April 2022 07:26 UTC

Return-Path: <xipengxiao@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540993A1166 for <v6ops@ietfa.amsl.com>; Tue, 19 Apr 2022 00:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 6lhKJ-iHwStA for <v6ops@ietfa.amsl.com>; Tue, 19 Apr 2022 00:26:28 -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 D89243A115A for <v6ops@ietf.org>; Tue, 19 Apr 2022 00:26:27 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KjFd13t11z686x7; Tue, 19 Apr 2022 15:22:45 +0800 (CST)
Received: from fraeml712-chm.china.huawei.com (10.206.15.61) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 19 Apr 2022 09:26:22 +0200
Received: from fraeml712-chm.china.huawei.com ([10.206.15.61]) by fraeml712-chm.china.huawei.com ([10.206.15.61]) with mapi id 15.01.2375.024; Tue, 19 Apr 2022 09:26:22 +0200
From: Xipengxiao <xipengxiao@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gábor LENCSE <lencse@hit.bme.hu>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] RFC8174 keywords -- Re: Some feedbacks - RE: I-D Action: draft-ietf-v6ops-hbh-01.txt
Thread-Index: AQHYU1MPuFHyvdAh80WO4jhH2prpKaz2G7eAgAC3XpA=
Date: Tue, 19 Apr 2022 07:26:22 +0000
Message-ID: <dde216d1d89b4acaaffed7a771eb4394@huawei.com>
References: <f75d0ee0b9bd43a8b1a77905f2ce43a8@huawei.com> <afb191fa-75e8-af54-b4a9-8bc2997f074d@hit.bme.hu> <ae3e9bca-ace0-fcc6-d32c-c63711b03496@gmail.com>
In-Reply-To: <ae3e9bca-ace0-fcc6-d32c-c63711b03496@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.207.66]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1JsgsWTqAVLr__ksvxaYzikPStw>
Subject: Re: [v6ops] RFC8174 keywords -- Re: Some feedbacks - RE: I-D Action: draft-ietf-v6ops-hbh-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2022 07:26:33 -0000

Hi Brian, Gabor,

Thank you very much for your input on the keywords.  To me, an informational RFC provides information for people to consider.  It's up to people to decide whether to follow.  Therefore, it should not be specifying requirements or use MUST/MUST NOT keywords which are mandatory to follow.  I know in ETSI, every requirement document must be a TS (i.e. standard track), not a TR (informational).

So if an informational RFC can also use MUST/MUST NOT key words, what is the difference between "informational" and "standard track"?  This is a sincere question not a challenge.

Thank you!

XiPeng 

-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
Sent: Tuesday, April 19, 2022 12:16 AM
To: Gábor LENCSE <lencse@hit.bme.hu>; v6ops@ietf.org
Subject: Re: [v6ops] RFC8174 keywords -- Re: Some feedbacks - RE: I-D Action: draft-ietf-v6ops-hbh-01.txt

On 19-Apr-22 06:31, Gábor LENCSE wrote:
> Dear XiPeng
> 
> First of all, you are welcome as our third WG chair, and thank you for 
> your kind offer that you read all drafts! :-)
> 
>> 7.	P11, the key words "MUST/MUST NOT, SHOULD/SHOULD NOT": if I understand RFC8174 correctly, only standard track documents can use these key words in capital case.
> I think that there is no such restriction.

That's correct. RFC8174 says it carefully:

"In many IETF documents, several words, when they are in all capitals
  as shown below, are used to signify the requirements in the
  specification."

RFC2119 said "In many standards track documents..." but that was changed by RFC8174.

     Brian

> 
> E.g. BMWG issues only informational documents and the capitalized 
> versions are used e.g. in RFC2544, RFC5180 and RFC8219.
> 
> (I admit that they are de facto standards, but formally they are 
> informational RFCs.)
> 
> Best regards,
> 
> Gábor
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

v2.41.0 | Report a Bug | By Email | System Status