Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

[Rafa Marin Lopez <[e-mail]>]

Hi Linda:
> El 22 may 2019, a las 0:06, Linda Dunbar <[e-mail]> escribió:
> 
> Rafa and Gabriel:
> 
> How about reference the module ietf-access-control-list specified in RFC8519 to avoid enumerating all the L4 protocols listed in IANA?
> 
Mmmm… I do not think it is required to reference that module. Actually my suggestion was precisely the one defined in that RFC (defining an uint8 and just that)

leaf protocol {
      type uint8;
      description
        "Internet Protocol number.  Refers to the protocol of the
         payload.  In IPv6, this field is known as 'next-header',
         and if extension headers are present, the protocol is
         present in the 'upper-layer' header.";
      reference
        "
RFC 791
: Internet Protocol
         
RFC 8200
: Internet Protocol, Version 6 (IPv6) Specification.";
    }


> The Module ietf-access-control-list specified in RFC8519 only list TCP and UDP and have ICMP defined using Type/Code (both uint8).
> 
> Maybe import the "grouping acl-icmp-header-fields", and augment the L4 protocol values that are not specified by the RFC8519?  
> 
> Many protocols values listed in https://www.iana..org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers..xhtml> are obsolete. There is no reason to enumerate them in your draft.
> 
Agree. But now we would have to select which protocol to include. 

Best Regards.
> My two cents. 
> 
> Linda
> 
> 
> 
> On Tue, May 21, 2019 at 3:02 AM Rafa Marin-Lopez <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Linda: 
> 
> In order to see whether we are in the same page here I would like to ask a question.
> 
> What Yoav and Paul (and us) suggested was something as simple as this one:
> 
> typedef ike-integrity-algorithm-t 
> 
> {
> 			type uint32; 
> 			description 
> 				“The acceptable numbers are defined in IANA Registry - Internet
> Key Exchange Version 2 (IKEv2) Parameters - IKEv2  Transform Type 1 - Encryption Algorithm Transform IDs";
> }
> 
> Following this approach we can solve easily Paul Wouters’ comment by replacing this with (for example):
> 
> Option 1)
> 
> typedef ipsec-upper-layer-proto {
>          	type uint8;
> 		description “ The IPsec protection can be applied to specific IP
> 				 traffic and layer 4 traffic (TCP, UDP, SCTP...) or
> 				 ANY protocol in the IP packet payload.”;
> 		reference “IANA Registry Protocol Numbers”;
> }
> 
> 
> However if we have to include a type enumeration with one enum and the value in the IANA registry per enum we would have something like (in my opinion more complex)
> 
> Option 2)
> 
> typedef ipsec-upper-layer-proto {
>        type union {
>            type uint8; 
>            type enumeration {
>                enum ICMP {
>                    value 1;
>                }
>                enum IGMP {
>                    value 2;
>                }
>                … 
> //And this enum per each value in https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers..xhtml>
>            }
>        }
>    }
> 
> 
> So what option (1 or 2) are you referring to?
> 
> Best Regards.
> 
>> El 17 may 2019, a las 17:39, Linda Dunbar <[e-mail] <mailto:[e-mail]>> escribió:
>> 
>> Rafa,
>>  
>> With regard to Paul Wouters’ related comment that would imply include every number from the IANA protocol registry:  "I think you mean what I would call the "inner protocol" so that it is every number from the IANA protocol registry.” 
>>  
>> I suggest we follow the IETF practices for YANG models:
>> There are many YANG models RFCs literally listed the names of the data types defined by other RFCs. For example: draft-ietf-teas-yang-te-types-09 which I just reviewed as a Gen-Art Directorate. 
>> None of those values are registered to IANA
>>  
>> Those IETF practices tell us that it is not necessary to register those values registered to IANA.
>> So I suggest you take the “reasonable approach proposed by Yoav (Paul Wouters agreed) and we are agreed”.
>>  
>> There are also many YANG Model RFCs literally list down the protocol values registered in IANA (for example, use “Identity ...” to specify the value).
>>  
>> By the way, if you do want to register to IANA, you can send the following request which can be easily done.
>>  
>> https://www.iana.org/form/protocol-assignment <https://www.iana.org/form/protocol-assignment>
>>  
>>  
>> Cheers,
>>  
>> Linda
>>  
>>   <>
>> From: Rafa Marin Lopez [mailto:[e-mail] <mailto:[e-mail]>] 
>> Sent: Friday, May 17, 2019 4:19 AM
>> To: Linda Dunbar <[e-mail] <mailto:[e-mail]>>
>> Cc: Rafa Marin Lopez <[e-mail] <mailto:[e-mail]>>; Yoav Nir <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Gabriel Lopez <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
>>  
>> Dear Linda, Yoav:
>>  
>> Sorry for the delay in our answer (very busy weeks)
>>  
>> The update is taking longer as expected for several reasons: 1) we have to add and extend many descriptions we have. 2) Moreover Paul Wouters' second review (we are preparing an e-mail for him as well) is long, deserves attention and implies to applies changes.
>>  
>> Finally, 3) it is important to note that, under our point of view, there is no final resolution about what to do with the IANA Registry values related with crypto algorithms. In fact, there is a Paul Wouters’ related comment that would imply include every number from the IANA protocol registry:  "I think you mean what I would call the "inner protocol" so that it is every number from the IANA protocol registry.” 
>>  
>> Depending on the resolution of the IANA Registry part , it may imply to add each value in the IANA protocol registry. For us, this is pointless. We think the reasonable approach was proposed by Yoav (Paul Wouters agreed) and we are agreed. The only review we have received from the YANG doctor does not mention anything about this. 
>>  
>> Our hope is to have the updated version, assuming 3) takes a “reasonable” solution, at the end of this month (May)
>>  
>> Best Regards.
>>  
>>  
>> El 15 may 2019, a las 18:30, Linda Dunbar <[e-mail] <mailto:[e-mail]>> escribió:
>>  
>> Rafa,
>>  
>> Will you upload the revised draft soon? We would like to close the WGLC for this draft.
>>  
>> Thanks, Linda
>>  
>> From: Linda Dunbar 
>> Sent: Thursday, April 18, 2019 9:14 AM
>> To: 'Rafa Marin-Lopez' <[e-mail] <mailto:[e-mail]>>; Yoav Nir <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Cc: Gabriel Lopez <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Subject: RE: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
>>  
>> Rafa, et al,
>>  
>> Yes, please have the revision to address the comments from YANG doctors.
>>  
>> Linda
>>  
>> From: Rafa Marin-Lopez [mailto:[e-mail] <mailto:[e-mail]>] 
>> Sent: Thursday, April 18, 2019 1:56 AM
>> To: Linda Dunbar <[e-mail] <mailto:[e-mail]>>; Yoav Nir <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Cc: Rafa Marin-Lopez <[e-mail] <mailto:[e-mail]>>; Gabriel Lopez <gabilm@um..es <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]>
>> Subject: Fwd: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
>>  
>> Dear Linda:
>>  
>> Just a short comment. In a previous e-mail, we thought we agreed that we would prepare version 05 *before* the beginning of the WGLC. At least that was your positive answer to our question.
>>  
>> In any case, I guess we can still prepare version 05 with pending comments we received from the last IETF and another aspects we have observed in the model, including YANG doctors’ comments. Correct? 
>>  
>> Best Regards
>>  
>>  
>> 
>> Inicio del mensaje reenviado:
>>  
>> De: Linda Dunbar <[e-mail] <mailto:[e-mail]>>
>> Asunto: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04
>> Fecha: 17 de abril de 2019, 16:54:13 CEST
>> Para: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>  
>> Hello Working Group, 
>>  
>> This email starts a four weeks Working Group Last Call on draft-ietf-i2nsf-sdn-ipsec-flow-protection-04. 
>> This poll runs until May 15, 2019. 
>>  
>> Authors: please update the draft per the comments and suggestions from YANG Doctors.
>>  
>> We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>> If you are listed as an Author or a Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
>>  
>> If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
>>  
>>  
>> Thank you. 
>>  
>> Yoav & Linda
>> _______________________________________________
>> I2nsf mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
>>  
>> _______________________________________________
>> I2nsf mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
> -------------------------------------------------------
> Rafa Marin-Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: [phone] Fax: [phone] e-mail: [e-mail] <mailto:[e-mail]>
> -------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf