Hi Linda:
> El 22 may 2019, a las 0:06, Linda Dunbar <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>]
>> Sent: Friday, May 17, 2019 4:19 AM
>> To: Linda Dunbar <[email protected] <mailto:[email protected]>>
>> Cc: Rafa Marin Lopez <[email protected] <mailto:[email protected]>>; Yoav Nir
>> <[email protected] <mailto:[email protected]>>; [email protected]
>> <mailto:[email protected]>; Gabriel Lopez <[email protected]
>> <mailto:[email protected]>>; [email protected]
>> <mailto:[email protected]>
>> 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 <[email protected]
>> <mailto:[email protected]>> 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' <[email protected] <mailto:[email protected]>>; Yoav Nir
>> <[email protected] <mailto:[email protected]>>; [email protected]
>> <mailto:[email protected]>
>> Cc: Gabriel Lopez <[email protected] <mailto:[email protected]>>;
>> [email protected] <mailto:[email protected]>
>> 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:[email protected] <mailto:[email protected]>]
>> Sent: Thursday, April 18, 2019 1:56 AM
>> To: Linda Dunbar <[email protected] <mailto:[email protected]>>;
>> Yoav Nir <[email protected] <mailto:[email protected]>>;
>> [email protected] <mailto:[email protected]>
>> Cc: Rafa Marin-Lopez <[email protected] <mailto:[email protected]>>; Gabriel Lopez
>> <[email protected] <mailto:[email protected]>>;[email protected]
>> <mailto:[email protected]>
>> 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 <[email protected] <mailto:[email protected]>>
>> 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: "[email protected] <mailto:[email protected]>" <[email protected]
>> <mailto:[email protected]>>
>>
>> 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
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/i2nsf
>> <https://www.ietf.org/mailman/listinfo/i2nsf>
>>
>> _______________________________________________
>> I2nsf mailing list
>> [email protected] <mailto:[email protected]>
>> 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: +34868888501 Fax: +34868884151 e-mail: [email protected] <mailto:[email protected]>
> -------------------------------------------------------
>
>
>
>
> _______________________________________________
> I2nsf mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i2nsf
> <https://www.ietf.org/mailman/listinfo/i2nsf>
> _______________________________________________
> I2nsf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
