Re: [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

tom petch <daedulus@btconnect.com> Fri, 06 November 2020 12:38 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C128B3A1133; Fri, 6 Nov 2020 04:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level:
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 A937ukeuCo7N; Fri, 6 Nov 2020 04:37:58 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40096.outbound.protection.outlook.com [40.107.4.96]) (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 3F7DD3A1132; Fri, 6 Nov 2020 04:37:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f4ADmYyEHPAcl+7dJHb9rv1qdgdzS7Y21xYqbNgD+I61eJGz2wwKOfHVxbw8rDf4MN+1ybVOFORSGJGzIA9lZSQZcPkrnQadaw2u/Ld3biq982KLx7LgHGFAGwXmIYIAF1SHpjmltCFb7JEb+wJnO/yrSV/Ozn3cnUM4Ja9/fcDDB8csYZkpUBWfNYF/0Yd4CdcDE2QTdZlbAxcdLsRLD4TK/Nn7/VfCKM6+9iiowuiuy4TfbdH98nkpeifhy+7YlFsTVVpj5Lrycu0wpId7ptTfYvIfRNFs+WR6RmtfsX60YOKZs969V6AElkeH2KxBC1ek3ZXx4swt65AJ02CMZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p+1GzgfVQwdzA9PmIAQWRlpVflVSKvYcB/Uhxr/L6IQ=; b=ZOkgGz9qEaAswAzs2SSIbxAHqRNjHTtbRT1wo8yjoELGMxK2jpsgABGudBnPy4quQ9AXWbzflmgREWj5TblIxXb66vDgiOHF5DxR9DLQEqRCWFqs0/fLM8eHzLj8wgz0aEUqPo5KxG8J58DloItH7AR5Fz9l87Wfg4E9oNqrbuzQ+s15RzXJ+KP6h/U2v1Q6qxt+E6OrL0x3FIqAB3WYrgK+Ss1iMfPKMzuU1lUFhfQjJF0tIHVnBtrlmuooynPIIY2iAPEnwhhbcD2HFwN9s2wjnNW01VZx7gyOsGT+gwVe461+5IN+3+woxKrsoE+IUZr1vQCXQq5N4yQ3GpZRDQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p+1GzgfVQwdzA9PmIAQWRlpVflVSKvYcB/Uhxr/L6IQ=; b=M1QWZWsFR7TApbXu20QH0xxCrfJi3EOWGI0jAK/mOmrZPi9LnFFZg+d31nFABT8mR30eG8eDuRAhbGLtNnzfZCdkSzV6n2PGTz/VJCbvY6n2qx8vbP4DG/shvAjNjaO/TxwCTT9jiAslqZ0Fc0wpN8se5fySiR4Y3mKp74NTjNA=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB6447.eurprd07.prod.outlook.com (2603:10a6:800:134::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Fri, 6 Nov 2020 12:37:53 +0000
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3564.013; Fri, 6 Nov 2020 12:37:53 +0000
To: Rafa Marin-Lopez <rafa@um.es>
References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AF68D.7060105@btconnect.com> <EC88EEFE-5F98-487A-9294-F78B99AC9C47@um.es> <5F9FF661.4080101@btconnect.com>
Cc: i2nsf@ietf.org, Fernando Pereniguez-Garcia <fernando.pereniguez@cud.upct.es>, Gabriel Lopez <gabilm@um.es>, ynir.ietf@gmail.com, last-call@ietf.org
From: tom petch <daedulus@btconnect.com>
Message-ID: <5FA5439B.40100@btconnect.com>
Date: Fri, 06 Nov 2020 12:37:47 +0000
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <5F9FF661.4080101@btconnect.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [86.146.121.140]
X-ClientProxiedBy: LO2P265CA0334.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a4::34) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0334.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a4::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3541.21 via Frontend Transport; Fri, 6 Nov 2020 12:37:52 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 84f60b4f-c44d-4932-0f81-08d88250c788
X-MS-TrafficTypeDiagnostic: VI1PR07MB6447:
X-Microsoft-Antispam-PRVS: <VI1PR07MB6447731F9E0940F7B0CFC0C5C6ED0@VI1PR07MB6447.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: WblRv0RftzZsF8tDqHb26zpf5xhKjH9jHQjVsj600hYjEfTtttwIaeXwArTX/fy1jG5E8ITL8Oa6kgBVMBLp7w21L2GLwg+ors8AmleZO49SVuPt0wAktJ4JLQbs3JHNoe8XBpE+JrgAVFYEn4fjwaI13MR3QysOSOHwmUD3y5bV6U3CLItX499y3FeBJJxfMiNWybubwE1Zofy6AEOEZifYQgzLfUwEqdsLabs9GEqYVcqpmGOFfIhRTM/JjHOUcua8GmR60dv9XXCVe1PJjrUaRHEv+v7kUeT/qxfl6bPkOez4UznW07AQxbMO8WHpfUto5MNdJGV2qbmR7IefZ/vZaRAPjvaqHhsB7+O6JkOerRaN1BVWeehLgbjLhFu2gowgxg2LIWDUTxI4WLWWOrwTcTSr5LFtg412PhUIVf7zIwC2FX6cFIfH41fZY3tWMIhzgrUYqjm/PCKQVSK3TQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(346002)(376002)(366004)(396003)(66476007)(4326008)(6486002)(66574015)(956004)(66946007)(966005)(186003)(30864003)(33656002)(26005)(66556008)(2616005)(36756003)(54906003)(5660300002)(2906002)(6666004)(53546011)(86362001)(52116002)(6916009)(478600001)(316002)(15650500001)(16576012)(83380400001)(8936002)(4001150100001)(8676002)(16526019)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: k5A7jKDth4jvnkFp7vFANwByHkHoI/faAQjxzg9M3ASPyyr/HW+rtJ2FTCW+qPQIvqoqnFHxaiGvpBJ+rFGCNTroDMt6D1ETtY7YTr3HtnvuVekPPU3dMv8+NEHs/QzS6lj1CgBijnTMri6DtcHXbk7wZOtcO2rtd8Aws/jSAtTwJYSGx8ckMG6RlWBCcGTctf20Pt70aQa7ufkQ4YYvcOTGd1+lk0B30W3f2RL+NT1cJ+MZw5jjh+MJTvvTpJT0pyQI3l3/W4X64uqCX1DrytWnhIbOJkgqmbdtc+rasc23YThBPI6mAL0N3YFSBHla1ifDpzs7gHssS9ea67N3IMS+8EeIGOVaaSmJW+SKP3mPd/Hy4OZG4Pbps4yYEikqkVpgLwG+pvbTbPRvPvn8ia0Q9feIOqmBy8t2bRC+7/V0mB79LAgbiFYVDUmKF8Ew+hPkIezahEjFtLB2fJ1ewDqPy5nIpQ7zCydvdCg5gfzRMb/GokquFNO5JxAlNELRLIKEuJlWqROHzGcoB4kxJYdKQ0Smf6p9PCZTUjHiE46tC5fSgaePWMR3tO7QbvW7eYXe2OQYTLvk5F5wumpha/ewbm9GV3RpqJf3nM8ccoGOaqyvkiutellcTO360PH9slDgH65GbvzE/MdVc2wusA==
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84f60b4f-c44d-4932-0f81-08d88250c788
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2020 12:37:53.3106 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4HnuMAz87kE0sdUXUOYXYLHdylc3mEvn887aLwJkcTniCtt1eubxKKK1yf5sL06+RPtwphqjnYeLvqhBfXUyWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6447
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/ymyDUoPDLD5Xp1ahJRKEImWgJp8>
Subject: Re: [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 12:38:02 -0000

Rafa

My attempt to read the text keeps running into a brick wall (lockdown:-( 
but I have a few new comments.  I said sometime ago that the IESG would 
likely find plenty to say and I see that Benjamin has lived up to my 
expectations.  I wish I could be as productive as him:-(

For completeness, I include what I have found so far but suspect that 
they will all be overtaken by IESG comments.

RFC2247 I don't find good for DN; I find RFC4519 better but suspect that 
X.520 would be better still but do not have a copy of that to hand; this 
is the sort of thing I expect the IESG to have definite views on

given that the model has a boolean for fragmentation should is also have 
a leaf or some such for PMTU? Doing the former requires the latter or is 
that latter expected to be elsewhere in a different YANG model?

Abstract; PAD, SPD, SAD need expanding or else leaving out if the 
reference to IPsec databases is adequate for the Abstract.

I know you added the comment about no protocol (the comment surprised 
me:-) but I think the YANG modules matter more so I would say
'It defines three YANG modules but no new protocol.'

1
/Inspired in the SDN/Inspired by the SDN/
3
/state date/state data/

4.1
'a YANG data model  .. MUST be defined'
it would be good to reference where they are, ie the Appendices

4.2
ditto

[which is as far as I got reading but ..]

8
/should adhere/SHOULD adhere/  ??

Tom Petch

On 02/11/2020 12:06, tom petch wrote:
> Rafa
>
> As you may know, the submission window closes in the week before the
> IETF meeting which is perhaps why over 150 new I-D have just appeared:-(
> which may or may not affect your plans. I expect to look some more this
> week but the country is going into lockdown for four weeks, some are
> saying for six months, so I need to work out what I have to get done
> before all the places I need to go shut:-(  Some things pre-empt IETF work!
>
> On the formatting, my hope was that the paragraphs of text as in YANG
> description would spread out to occupy fewer lines, so fixing the
> indentation is an improvement but not quite all I had hoped for - it
> certainly makes it easier to read.  I would not reissue a new version
> just for this
>
> And inline twice
>
>
> On 30/10/2020 17:43, Rafa Marin-Lopez wrote:
>> Hi Tom:
>>
>> Thank you very much again. See our comments inline:
>>
>>> El 29 oct 2020, a las 18:06, tom petch <daedulus@btconnect.com>
>>> escribió:
>>>
>>> Back to routine comments on this I-D; I don't think that any of my
>>> earlier ones are unresolved.
>>>
>>> On 29/10/2020 11:23, Rafa Marin-Lopez wrote:
>>>> Hi Tom:
>>>>
>>>>> El 28 oct 2020, a las 19:02, tom petch <daedulus@btconnect.com>
>>>>> escribió:
>>>>>
>>>>> On 28/10/2020 10:42, Rafa Marin-Lopez wrote:
>>>>>> Hi Tom:
>>>>>>
>>>>>> Thank you very much for your insight. It is very helpful. Please
>>>>>> see our comments/questions inline.
>>>>>>
>>>>>>> El 27 oct 2020, a las 13:42, tom petch <daedulus@btconnect.com>
>>>>>>> escribió:
>>>>>>>
>>>>>>> I think that the IESG will find a number of problems with this I-D.
>>>>>>>
>>>>>>> YANG module references RFC822 which is several years out of date
>>>
>>> Rafa
>>>
>>> Several YANG leaf are in seconds, eight I think, but none use the YANG
>>> units seconds;
>>> statement.  I suggest adding it.
>>
>> Added. They are seven.
>
> I still see eight - the one that lacks units is
> leaf established
>
>>> typedef ipsec-spd-action
>>> capitalises the actions as does RFC4301 but later uses of this have
>>> lower case actions; probably ok as it is
>>
>> Ok.
>>>
>>> protocol number appears in several places but technically, IPv6,
>>> which we must all love and promote, has 'next header' instead.
>>> Probably worth a mention at least once in the YANG module
>>
>> We have included this note:
>>
>> NOTE: In case of IPv6, the protocol in the IP packet payload is
>> specified in the Next Header field of the IPv6
>> packet.";
>>>
>>> On the start >= end, I was looking at nat-yang and it has
>>> must ". >= ../start-port-number"
>>> which is the sort of YANG constraint I had in mind
>>
>> Done.
>>
>> must '. >= ../start’
>>
>>> leaf dscp-mapping
>>> I do not understand, a hex string of indeterminate length for DSCP
>>> values (plural).  I expect DSCP to be six bit and values to be a
>>> leaf-list
>>
>> Right. Since we have inet:dscp type , we have used that one in a
>> leaf-list as you recommend.
>>
>> leaf-list dscp-mapping {
>>         type inet:dscp;
>>         default 0;
>>         description
>>           "DSCP values allowed for packets carried over
>>           this IPsec SA.";
>>         reference
>>           "Section 4.4.2.1. in RFC 4301.";
>>       }
>>
>>>
>>> leaf ecn
>>> /Annex C/Appendix C/
>>
>> Fixed.
>>>
>>> I see that RFC8247 gives AEAD status which is a good reference to
>>> have except that as my other post today says there is no requirement
>>> for any future additions to the IANA data to include this
>>> information; IANA for IKEv2 needs updating iun a separate I-D!
>>>
>>> leaf mask
>>> hex-string with no length specified
>>
>> Since this masked is after all 32-bits mask we have used uint32 instead.
>>>
>>> leaf ds-algorithm
>>> default 1
>>> which I think is RSA; worth stating as it might raise some AD eyebrows
>>
>> Clarified in the description.
>>>
>>> pfs-groups
>>> /it is required perfect forward secrecy/perfect forward secrecy is
>>> required/
>>
>> Fixed.
>>
>>> and a reference to Transform Type 4?
>>
>> As we mention earlier, this pfs-groups used the type pfs-group, which
>> includes the reference to Transform Type 4.
>>>
>>> leaf ext-seq-num
>>> /FALSE/false/ or /False/?
>>>
>>> leaf encryption-algorithm (twice, in separate containers)
>>
>> Mmmmm… we only see in one place.
>
> I see it a second time for
> leaf integrity-algorithm
>
>
> Tom Petch
>
>>> /the integrity leaf/ the integrity-algorithm leaf/
>>
>> Fixed.
>>>
>>> I have yet to look at the text or the examples, probably next week.
>>
>> Thank you very much. We are going to post -12 with all these comments
>> and the previous ones so far. If there are pending comments we can
>> prepare -13 right away.
>>
>> Best Regards.
>>>
>>> Tom Petch
>>>
>>>>> On boiler plate, I mean the reference to RFC2119 which now must use
>>>>> the language from RFC8174 in the body of the I-D; sorry for the
>>>>> confusion.
>>>>
>>>> Ah ok. I guess you are referring to change that paragraph with this:
>>>>
>>>>
>>>> The key words "MUST", "MUST NOT", "REQUIRED",
>>>> "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>>>> "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>>> "OPTIONAL" in this document are to be interpreted
>>>> as described in BCP 14 RFC2119 RFC8174 when,
>>>> and only when, they appear in all capitals,
>>>> as shown here.
>>>>
>>>>>
>>>>> On XXXX, you have XXXX standing in for more than one RFC-to-be
>>>>> which confuses.  The convention is to use XXXX for this I-D and
>>>>> then AAAA BBBB etc for any others such as the netconf I-D in this
>>>>> instance.
>>>>
>>>> Ah ok. In any case, we have now only XXXX for our RFC-to-be so
>>>> problem fixed.
>>>>>
>>>>> Two big issues, for me (perhaps not for others).  The convention
>>>>> with YANG is for each successive line to be indented two
>>>>> characters, you have four, which creates a lot of white space and
>>>>> pushes the text to the right hand margin.  I think that two
>>>>> characters is the default when you use pyang to format a YANG module.
>>>>
>>>> We can try to reduce it to two characters.
>>>>
>>>>>
>>>>> And references.  I have had to work harder than I want to to make
>>>>> sense of the IANA references.  I think you should have five
>>>>> separate references in the I-D for IANA for
>>>>> Transform Type 1
>>>>> Transform Type 3
>>>>> Transform Type 4
>>>>> Authentication Method
>>>>> Protocol Numbers
>>>>> and each reference in the I-D should have a URL pointing to the
>>>>> specific section of IANA web site.
>>>>
>>>> Ok, good. This follows what we thought.
>>>>
>>>>> In the YANG, it is harder to know what to do.  Those first three
>>>>> references are in the third tier i.e.
>>>>> Group - Internet Key Exchange V2 (IKEv2) Parameters
>>>>> Registry  -Transform Attribute Types
>>>>> and then Type 1, 3, 4 as the third tier as I am calling it
>>>>> and I think that every reference in the YANG should give me all
>>>>> three tiers after IANA in that order perhaps
>>>>> IANA; IKEv2 Parameters; Transform Atribute Types; Transform Type 1
>>>>
>>>> Great. We also considered this as a possible solution after sending
>>>> our e-mail. Let’s do it.
>>>>
>>>>> If the syntax needs tweeking, then the RFC Editor will do a good
>>>>> job of that but at present the references are inconsistent in which
>>>>> elements are specified in what order and that is something the RFC
>>>>> Editor probably cannot cope with.
>>>>> Authentication Method is a registry so that just needs Group name
>>>>> and Registry name after IANA.
>>>>
>>>> Ok, good.
>>>>>
>>>>> Some minor glitches.
>>>>> I-D appears twice in the body of the I-D - perhaps document or memo.
>>>>
>>>> Ok.
>>>>
>>>>> objetives/objectives/
>>>>
>>>> Fixed.
>>>>> end port number perhaps /must/MUST/
>>>>
>>>>> and YANG is very good at including such checks with a must ....
>>>>> 'If AEAD is used .. where? this occurs in several places and I
>>>>> think that you need to specify the leaf where AEAD will be
>>>>> specified or implied.
>>>>
>>>> Ok we have changed it to:
>>>>
>>>> If Authenticated Encryption with Associated Data (AEAD) is used
>>>> (leaf esp-algorithms/encryption/algorithm-type)
>>>> this flag MUST be false."
>>>>
>>>>> And is it possible to make that a YANG 'must' statement - looking
>>>>> at the IKEv2 registries it is not obvious which are AEAD so that
>>>>> might be more complexity than it is worth.
>>>>> 'only available on linux kernels' Um implementation detail, you may
>>>>> get asked to remove that altogether or at least to a Informative
>>>>> Appendix - I would leave it in for now.
>>>>
>>>> Ok.
>>>>
>>>>> 'import ietf-i2nsf-ikec' the reference needs to be to a RFC and if
>>>>> it is not yet an RFC then RFC XXXX <title> in both Appendix B and C
>>>>
>>>> Yes, we have changed that to:
>>>>
>>>> RFC XXXX: Software-Defined Networking
>>>>                 (SDN)-based IPsec Flow Protection.
>>>>
>>>>> leaf-list pfs-groups could do with a reference - Transform Type 4?
>>>>
>>>> The leaf list is referring to type pfs-group and we have now
>>>>
>>>> typedef pfs-group {
>>>>              type uint16;
>>>>              description
>>>>                  "DH groups for IKE and IPsec SA rekey.";
>>>>              reference
>>>>                  "IANA; Internet Key Exchange V2 (IKEv2) Parameters;
>>>>                 Transform Atribute Types; Transform Type 4 -
>>>>                  Diffie-Hellman Group Transform IDs.
>>>>                 Section 3.3.2 in RFC 7296.";
>>>>          }
>>>>
>>>>
>>>>> I am still working my way through the YANG so may have some more
>>>>> comments tomorrow.
>>>>
>>>> Ok, do not worry we will work in -12 with these comments so far to
>>>> have a quick response. We can prepare a another version later with
>>>> the rest of them.
>>>>
>>>> Thank you very much for your effort.
>>>>>
>>>>> Tom Petch
>>>>>
>>>>>> We have realized that we missed to change this, even though we
>>>>>> discussed it. We will change it right away in the following way
>>>>>> (bold):
>>>>>>
>>>>>> case rfc822-address-string {
>>>>>>       leaf rfc822-address-string {
>>>>>>            type string;
>>>>>>            description
>>>>>>                "Specifies the identity as a
>>>>>>                 fully-qualified RFC5322 email
>>>>>>                 address string. An example is,
>>>>>>                 jsmith@example.com. The string
>>>>>>                 MUST NOT contain any
>>>>>>                 terminators e.g., NULL, CR,
>>>>>>                 etc.).";
>>>>>>             reference
>>>>>>                    "RFC 5322.";
>>>>>>       }
>>>>>> }
>>>>>>
>>>>>> Btw, we already used in the past “case rfc822-address-string” and
>>>>>> “leaf rfc822-address-string” since this is coming from IKEv2
>>>>>> standard. Do you think we should change that name as well?
>>>>>>> YANG module references IANA Protocol Numbers which is not in the
>>>>>>> I-D references
>>>>>>
>>>>>> We have included the following reference:
>>>>>>
>>>>>> [IANA-Protocols-Number]
>>>>>>                Internet Assigned Numbers Authority (IANA), "Protocol
>>>>>>                Numbers", January 2020.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> s.2 boiler plate is out of date
>>>>>>
>>>>>> What we see is the I-D has the second choice stated in
>>>>>> https://www.ietf.org/standards/ids/guidelines/
>>>>>>
>>>>>> This Internet-Draft is submitted in full conformance with the
>>>>>>     provisions of BCP 78 and BCP 79.
>>>>>>
>>>>>>     Internet-Drafts are working documents of the Internet Engineering
>>>>>>     Task Force (IETF).  Note that other groups may also distribute
>>>>>>     working documents as Internet-Drafts.  The list of current
>>>>>> Internet-
>>>>>>     Drafts is at https://datatracker.ietf.org/drafts/current/.
>>>>>>
>>>>>>     Internet-Drafts are draft documents valid for a maximum of six
>>>>>> months
>>>>>>     and may be updated, replaced, or obsoleted by other documents
>>>>>> at any
>>>>>>     time.  It is inappropriate to use Internet-Drafts as reference
>>>>>>     material or to cite them other than as "work in progress."
>>>>>>
>>>>>> Could you refer what is out of date?
>>>>>>
>>>>>>>
>>>>>>> XXXX is standing in for more than one RFC
>>>>>>
>>>>>> Yes, XXXX has been used because we do not know the future number
>>>>>> assigned to our I-D.
>>>>>>
>>>>>> Also we realized we also included this to refer to crypto-types
>>>>>> I-D but this has been solved now in a new version -12 that we are
>>>>>> preparing to include your comments. We noticed we can replace the
>>>>>> type of rw cert-data?, ca-data*, crl-data? for binary without any
>>>>>> problem.
>>>>>>
>>>>>> |           |     +--rw cert-data?        binary
>>>>>> |           +--rw private-key?            binary
>>>>>> |           +--rw ca-data*                binary
>>>>>> |           +--rw crl-data?               binary
>>>>>>
>>>>>>>
>>>>>>> but the show stopper that makes a proper review of this too
>>>>>>> costly is the references.  Those to IANA of which there are
>>>>>>> several I want to pursue.  The I-D reference is to IKEv2
>>>>>>> parameters. Sadly, this is a three tier structure and noone
>>>>>>> agrees on what to call the third tier so I will call it tier3
>>>>>>> here.  Top level is Group, as per RFC8126, second level is
>>>>>>> Registry.  The I-D reference is to the Group only which is fine
>>>>>>> if the actual reference then specifies the Registry and Tier3 but
>>>>>>> they never do, usually just Tier3 e.g. Transform Type 3 which
>>>>>>> makes for a lot of work for the reader, too much for this one.
>>>>>>> You have to go hunting in all the second level Registry until you
>>>>>>> can find a match for the Tier3 identifier. And there are no URL.
>>>>>>> If you want an example that I find easy to use, go look at
>>>>>>> RFC8407 (as usual).
>>>>>>
>>>>>> You’re right. Could you point the exact part at RFC 8407 with that
>>>>>> example? We would really appreciate it.
>>>>>>
>>>>>> On the other hand, would it be enough to include the URL for
>>>>>> Transform Type 3
>>>>>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7
>>>>>> ?
>>>>>>
>>>>>> (Same for Transform Type 1, Transform Type 4)
>>>>>>
>>>>>>>
>>>>>>> The reference for import of i2nsf-ikec gives a YANG module name;
>>>>>>> this needs to be the name of the RFC to be
>>>>>>
>>>>>> Fixed.
>>>>>>
>>>>>> import ietf-i2nsf-ikec {
>>>>>>              prefix nsfikec;
>>>>>>              reference
>>>>>>                  "RFC XXXX: Software-Defined Networking
>>>>>>                 (SDN)-based IPsec Flow Protection.";
>>>>>> }
>>>>>>
>>>>>> We still use XXXX because we do not know the number assigned to
>>>>>> the RFC to be.
>>>>>>
>>>>>>>
>>>>>>> The example IPv6 address in the YANG module has :0:0: which is
>>>>>>> usually just ::
>>>>>>
>>>>>> Fixed.
>>>>>>
>>>>>> If you have any further comments, please let us know so we can
>>>>>> include them in -12
>>>>>>
>>>>>> Best Regards.
>>>>>>>
>>>>>>> And I have some way to go still.
>>>>>>>
>>>>>>> Tom Petch
>>>>>>>
>>>>>>> On 22/10/2020 18:39, Rafa Marin-Lopez wrote:
>>>>>>>> Dear all:
>>>>>>>>
>>>>>>>> After receiving a suggestion to make things clearer in the
>>>>>>>> feature ikeless-notification description, we have just uploaded
>>>>>>>> a new version -11 with a minor change to add the following text:
>>>>>>>>
>>>>>>>> feature ikeless-notification {
>>>>>>>>              description
>>>>>>>>                  "This feature indicates that the server supports
>>>>>>>>                  generating notifications in the ikeless module.
>>>>>>>>
>>>>>>>>                  To ensure broader applicability of this module,
>>>>>>>>                  the notifications are marked as a feature.
>>>>>>>>                  For the implementation of ikeless case,
>>>>>>>>                  the NSF is expected to implement this
>>>>>>>>                  feature.";
>>>>>>>>          }
>>>>>>>>
>>>>>>>> Best Regards.
>>>>>>>>
>>>>>>>>> Inicio del mensaje reenviado:
>>>>>>>>>
>>>>>>>>> De: internet-drafts@ietf.org
>>>>>>>>> Asunto: New Version Notification for
>>>>>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>>> Fecha: 22 de octubre de 2020, 15:32:50 CEST
>>>>>>>>> Para: "Fernando Pereniguez-Garcia"
>>>>>>>>> <fernando.pereniguez@cud.upct.es>, "Rafael Lopez" <rafa@um.es>,
>>>>>>>>> "Gabriel Lopez-Millan" <gabilm@um.es>, "Rafa Marin-Lopez"
>>>>>>>>> <rafa@um.es>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A new version of I-D,
>>>>>>>>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>>> has been successfully submitted by Rafa Marin-Lopez and posted
>>>>>>>>> to the
>>>>>>>>> IETF repository.
>>>>>>>>>
>>>>>>>>> Name:        draft-ietf-i2nsf-sdn-ipsec-flow-protection
>>>>>>>>> Revision:    11
>>>>>>>>> Title:        Software-Defined Networking (SDN)-based IPsec
>>>>>>>>> Flow Protection
>>>>>>>>> Document date:    2020-10-22
>>>>>>>>> Group:        i2nsf
>>>>>>>>> Pages:        92
>>>>>>>>> URL:
>>>>>>>>> https://www.ietf.org/archive/id/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
>>>>>>>>>
>>>>>>>>> Status:
>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
>>>>>>>>>
>>>>>>>>> Htmlized:
>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection
>>>>>>>>>
>>>>>>>>> Htmlized:
>>>>>>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>>>>>>>>
>>>>>>>>> Diff:
>>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-sdn-ipsec-flow-protection-11
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Abstract: