[IPsec] IKEv2 IANA registries, was Fwd: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt

[Paul Wouters <[e-mail]>]

I agree we should make our IANA entries clearer.

Begin forwarded message:

> From: Roman Danyliw <[e-mail]>
> Date: October 30, 2020 at 15:41:09 EDT
> To: tom petch <[e-mail]>
> Cc: [e-mail], [e-mail], Gabriel Lopez <[e-mail]>, [e-mail], Fernando Pereniguez-Garcia <[e-mail]>, [e-mail], Rafa Marin-Lopez <[e-mail]>
> Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
> 
> Hi Tom!
> 
>> -----Original Message-----
>> From: tom petch <[e-mail]>
>> Sent: Friday, October 30, 2020 7:14 AM
>> To: Roman Danyliw <[e-mail]>; Rafa Marin-Lopez <[e-mail]>
>> Cc: [e-mail]; Fernando Pereniguez-Garcia
>> <[e-mail]>; Gabriel Lopez <[e-mail]>;
>> [e-mail]; [e-mail]
>> Subject: Re: [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-
>> flow-protection-11.txt
>> 
>> Roman  not this I-D but see below
>> 
>>> On 29/10/2020 18:46, Roman Danyliw wrote:
>>> Hi Tom!
>>> 
>>>> -----Original Message-----
>>>> From: last-call <[e-mail]> On Behalf Of tom petch
>>>> Sent: Thursday, October 29, 2020 12:38 PM
>>>> To: Rafa Marin-Lopez <[e-mail]>
>>>> Cc: [e-mail]; Fernando Pereniguez-Garcia
>>>> <[e-mail]>; Gabriel Lopez <[e-mail]>;
>>>> [e-mail]; [e-mail]
>>>> 
>>>> Top posting a new, related issue that may need Security AD or WG
>>>> Chair to act on.
>>>> 
>>>> It seems to me that the IANA entries for IKEv2 are incomplete.
>>>> RFC8247 does a fine job of specifying algorithms and adding
>>>> information such as status (MUST/SHOULD+), IoT, AEAD and so on,
>>>> information which is not present on IANA.  The policy for, e.g.
>>>> Transform Type 1, is expert review and entries have been added via
>>>> draft-smyslov-esp-gont but the IANA entries lack this information
>>>> and, looking at the I-D, I see no such information (nor is there any
>>>> reason for it to be there).  Yet draft-ietf-i2nsf-sdn... needs this information
>> as references in the YANG module show.
>>>> 
>>>> It seems to me that this is a similar situation to that which the TLS
>>>> WG found itself in and which led to a revision of the TLS IANA
>>>> entries to provide what was needed via additional columns.
>>> 
>>> Please help me understand.  In particular, I'm not following why this
>> document should modify IKE IANA registries.  In my view, this document is
>> provides a data model to encode an "IKEv2 configuration" of sorts.  Certainly,
>> there are valid/invalid/incomplete/not recommended ways to provide a
>> configuration with this data model if one relied solely on the pointers to the
>> IANA registries from the YANG module definition.  However, as you noted,
>> RFC8247 already provides guidance on specifying a configuration (albeit this
>> guidance isn't fully encoded in the registries).  Furthermore, this document
>> states:
>>> 
>>> Section 8.1
>>>    o  IKEv2 configurations should adhere to the recommendations in
>>>       [RFC8247].
>>> 
>>> so there is guidance on producing a configuration.  What is missing?
>>> 
>>>> I think that the IANA pages for IKEv2 need revising so that that
>>>> additional information that RFC8247 provides is required as
>>>> additional columns in the IANA entries at least for Type 1, Type 2,
>>>> Type 3, Type 4 and Authentication Method.
>>> 
>>> While things could be clearer, I'm unsure of why _this YANG document_
>> should do a registry reengineering.  Did you mean it should be done in general?
>> 
>> Not this I-D but another I-D from a WG with closer links to IKEv2; I don't know
>> which WG that would be but a Security AD would:-)
> 
> Thanks for clarifying.  IPSECME (https://datatracker.ietf.org/wg/ipsecme/about/) (who has been cross-posted with this note)  is likely the best place to handle IPsec maintenance and the kind of registry modifications you describe below.
> 
> Regards,
> Roman
> 
>> This I-D, as you quote, points to RFC8247 for guidance and that is fine.
>>  But security moves on and new algorithms will be needed and this I-D also
>> points to the IANA registry, which is Expert Review, where new entries have
>> been added already; and for those the IANA Registry gives no guidance and the
>> I-D that IANA references for the new entries - written by the Expert Reviewer! -
>> also gives no guidance. Over time we are likely to accrue algorithms with no
>> guidance unless and until an RFC8247-bis appears or we require IANA to have
>> columns for guidance.
>> Currently the new algorithms are GOST and so perhaps of limited interest but
>> on the TLS list I am always seeing new algorithms appear and there the new
>> IANA entry is required to give guidance.  My sense is that IKEv2 is a bit slower
>> to take up new ones but, as with RFC8247, it does eventually.
>> 
>> I think that users need those extra columns that RFC8247 provides on the IANA
>> website so that when new algorithms are added by Expert Review, then that
>> guidance must be added as well.  This is what the TLS WG came round to and I
>> think that IKEv2 needs to do the same.
>> 
>> Tom Petch
>> 
>> 
>>> Regards,
>>> Roman
>>> 
>>>> Tom Petch
>>>> 
>>>> On 29/10/2020 11:23, Rafa Marin-Lopez wrote:
>>>>> Hi Tom:
>>>>> 
>>>>>> El 28 oct 2020, a las 19:02, tom petch <[e-mail]>
>> 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 <[e-mail]>
>>>> 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
>>>>>> 
>>>>>> 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,
>>>>>>>                 [e-mail]. 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: [e-mail]
>>>>>>>>>> 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"
>>>>>>>>>> <[e-mail]>, "Rafael Lopez" <[e-mail]>,
>>>>>>>>>> "Gabriel Lopez-Millan" <[e-mail]>, "Rafa Marin-Lopez"
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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:
>>>>>>>>>>    This document describes how to provide IPsec-based flow
>> protection
>>>>>>>>>>    (integrity and confidentiality) by means of an Interface to Network
>>>>>>>>>>    Security Function (I2NSF) controller.  It considers two main well-
>>>>>>>>>>    known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
>>>>>>>>>>    host.  The service described in this document allows the
>>>>>>>>>>    configuration and monitoring of IPsec Security Associations (SAs)
>>>>>>>>>>    from a I2NSF Controller to one or several flow-based
>>>>>>>>>> Network
>>>> Security
>>>>>>>>>>    Functions (NSFs) that rely on IPsec to protect data traffic.
>>>>>>>>>> 
>>>>>>>>>>    The document focuses on the I2NSF NSF-facing interface by
>> providing
>>>>>>>>>>    YANG data models for configuring the IPsec databases (SPD,
>>>>>>>>>> SAD,
>>>> PAD)
>>>>>>>>>>    and IKEv2.  This allows IPsec SA establishment with minimal
>>>>>>>>>>    intervention by the network administrator.  It does not define any
>>>>>>>>>>    new protocol.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Please note that it may take a couple of minutes from the time
>>>>>>>>>> of submission until the htmlized version and diff are available
>>>>>>>>>> at
>>>> tools.ietf.org.
>>>>>>>>>> 
>>>>>>>>>> The IETF Secretariat
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> 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]
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> -------------------------------------------------------
>>>>>>> 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]
>>>>>>> -------------------------------------------------------
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> -------------------------------------------------------
>>>>> 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]
>>>>> -------------------------------------------------------
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> last-call mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/last-call
> -- 
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call