Re: [Softwires] Alvaro Retana's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

" 杨术 " <yangshu@oudmon.com> Sun, 02 June 2019 15:31 UTC

Return-Path: <yangshu@oudmon.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B3212021F; Sun, 2 Jun 2019 08:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level:
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=no 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 WfEg-UfwsymP; Sun, 2 Jun 2019 08:31:16 -0700 (PDT)
Received: from SMTPBG352.QQ.COM (SMTPBG352.QQ.COM [183.57.50.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EF71201B4; Sun, 2 Jun 2019 08:31:04 -0700 (PDT)
X-QQ-GoodBg: 2
X-QQ-SSF: 00400000000000F0
X-QQ-FEAT: i/xzikqTSPbZkUtazHyeDdS0t0GmjPiUeDkUh341aLf1DrnP+RD4TR1n/tkpV Fxldb9flraCxAQKJsED0uWPdNISiUBt7bZgXm3gY7QmwWeHQ0wDyF951jGiE/H9vyhmM9tH dHU6JEB+BsO1UZPW7IWDksjHNRNS2ogz5lmasRP6JMS4dNfZxduyPCriYLuPTETSO7RvMt8 J2xoQ5hDmKnLz+Y1U22ZDq33sQcfRjcEGwVgvn6AiZaLeb6xgvq/ZtVM3LyAIojBisNqjOS raofif4dNGpZdhVJ65ve133uRMDxjpS51a8+p4hmATX3oK5WYUH3N/FVTDsBPPNg/dNQ==
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 61.51.59.75
X-QQ-STYLE:
X-QQ-mid: bizmailvip4t1559489459t577835
From: "=?utf-8?B?5p2o5pyv?=" <yangshu@oudmon.com>
To: "=?utf-8?B?QWx2YXJvIFJldGFuYQ==?=" <aretana.ietf@gmail.com>, "=?utf-8?B?VGhlIElFU0c=?=" <iesg@ietf.org>
Cc: "=?utf-8?B?c29mdHdpcmVz?=" <softwires@ietf.org>, "=?utf-8?B?ZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tZXNoLW11bHRpY2FzdA==?=" <draft-ietf-softwire-mesh-multicast@ietf.org>, "=?utf-8?B?c29mdHdpcmUtY2hhaXJz?=" <softwire-chairs@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_5CF3EBB3_0CB55DC8_3BA97630"
Content-Transfer-Encoding: 8Bit
Date: Sun, 2 Jun 2019 23:30:59 +0800
X-Priority: 3
Message-ID: <tencent_4FCF79FC2250DF2D750AB635@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-SENDSIZE: 520
Received: from qq.com (unknown [127.0.0.1]) by smtp.qq.com (ESMTP) with SMTP id ; Sun, 02 Jun 2019 23:31:00 +0800 (CST)
Feedback-ID: bizmailvip:oudmon.com:qybgweb:qybgweb7
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/y7eC--Ci3mPRUXUKmxRBmdc1-Bs>
Subject: Re: [Softwires] Alvaro Retana's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jun 2019 15:31:26 -0000

Dear Alvaro, 




Thank you for your detailed comments, 




(1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format".  Even
 
though source address mapping had just been discussed (§5.3), it wasn't clear
 
right away that you were talking about the same thing.  Maybe it was the name
 
used ("IPv4-Embedded IPv6 Virtual Source Address Format"), which doesn't show
 
up anywhere else.  Putting a note in §5.3 about the name would be nice.
 


 
We modified the name to be ""IPv4-Embedded IPv6 Source Address Format" [RFC6052].
 


 
(2) §5.4: "...every AFBR MUST announce the address of one of its E-IPv4
 
interfaces in the "v4" field..."  Please put a reference here to rfc6052 (so
 
it's easy to remember where that field came from).
 


 
We added a reference here. 
 


 
(3) §6.4: "According to [RFC7761], it SHOULD propagate..." That SHOULD is out
 
of place because it is not normative in this document.  Either change it to
 
'should', or quote the text.
 


 
We change it to “should”.
 


 
(4) §6.4: Several SHOULDs are used in this section.  In general, are there
 
cases where it's ok to not follow the specification?  For example, "When RP'
 
receives this encapsulated message, it SHOULD decapsulate..." -- are there
 
cases where the RP' wouldn't decapsulate.  IOW, why not use MUST instead?
 


 
We change it to “MUST”.
 


 
(5) §6.4: "...so RP' SHOULD NOT simply process this message as specified in
 
[RFC7761] on the incoming interface."  That "SHOULD NOT" seems to just be a
 
statement and not have normative value (the normative text comes in the next
 
paragraph).  s/SHOULD NOT/should not
 


 
We change the “SHOULD NOT” to “should not”.




Best Regards,




Shu Yang







------------------



杨术



欧德蒙科技有限公司






This message may contain privileged and confidential information only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately. 



 
 
 
------------------ Original ------------------
From:  "Alvaro Retana"<aretana.ietf@gmail.com>ail.com>;
Date:  Wed, Sep 26, 2018 11:49 PM
To:  "The IESG"<iesg@ietf.org>etf.org>; 
Cc:  "softwires"<softwires@ietf.org>res@ietf.org>; "draft-ietf-softwire-mesh-multicast"<draft-ietf-softwire-mesh-multicast@ietf.org>ast@ietf.org>; "softwire-chairs"<softwire-chairs@ietf.org>irs@ietf.org>; 
Subject:  [Softwires] Alvaro Retana's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

 

Alvaro Retana has entered the following ballot position for
draft-ietf-softwire-mesh-multicast-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) §5.4 mentions an "IPv4-Embedded IPv6 Virtual Source Address Format".  Even
though source address mapping had just been discussed (§5.3), it wasn't clear
right away that you were talking about the same thing.  Maybe it was the name
used ("IPv4-Embedded IPv6 Virtual Source Address Format"), which doesn't show
up anywhere else.  Putting a note in §5.3 about the name would be nice.

(2) §5.4: "...every AFBR MUST announce the address of one of its E-IPv4
interfaces in the "v4" field..."  Please put a reference here to rfc6052 (so
it's easy to remember where that field came from).

(3) §6.4: "According to [RFC7761], it SHOULD propagate..." That SHOULD is out
of place because it is not normative in this document.  Either change it to
'should', or quote the text.

(4) §6.4: Several SHOULDs are used in this section.  In general, are there
cases where it's ok to not follow the specification?  For example, "When RP'
receives this encapsulated message, it SHOULD decapsulate..." -- are there
cases where the RP' wouldn't decapsulate.  IOW, why not use MUST instead?

(5) §6.4: "...so RP' SHOULD NOT simply process this message as specified in
[RFC7761] on the incoming interface."  That "SHOULD NOT" seems to just be a
statement and not have normative value (the normative text comes in the next
paragraph).  s/SHOULD NOT/should not


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