BRUNGARD, DEBORAH A | 5 Feb 00:15 2016
Picon

FW: ID Tracker State Update Notice: <draft-ietf-l2tpext-keyed-ipv6-tunnel-05.txt>

Hi l2tpext,

This document needs to be updated from the expert review for some time now and as it will have changes, I
recommend it should have another WG Last Call. I've sent it back to the WG.

I hope you can progress the document quickly-
Thanks-
Deborah

-----Original Message-----
From: IETF Secretariat [mailto:ietf-secretariat-reply <at> ietf.org] 
Sent: Thursday, February 04, 2016 6:09 PM
To: cpignata <at> cisco.com; draft-ietf-l2tpext-keyed-ipv6-tunnel.all <at> ietf.org;
draft-ietf-l2tpext-keyed-ipv6-tunnel <at> ietf.org; l2tpext-chairs <at> ietf.org; BRUNGARD, DEBORAH A <db3546 <at> att.com>
Subject: ID Tracker State Update Notice: <draft-ietf-l2tpext-keyed-ipv6-tunnel-05.txt>

IESG state changed to AD is watching from Expert Review
ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/
internet-drafts | 3 Jan 14:01 2016
Picon

I-D Action: draft-ietf-l2tpext-sbfd-discriminator-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

        Title           : Advertising S-BFD Discriminators in L2TPv3
        Authors         : Vengada Prasad Govindan
                          Carlos Pignataro
	Filename        : draft-ietf-l2tpext-sbfd-discriminator-02.txt
	Pages           : 6
	Date            : 2016-01-03

Abstract:
   This document defines a new AVP that allows L2TP Control Connection
   Endpoints (LCCEs) to advertise one or more Seamless BFD (S-BFD)
   Discriminator values using L2TPv3.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-sbfd-discriminator-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Manav Bhatia | 31 Dec 13:55 2015

RtgDir review : draft-ietf-l2tpext-sbfd-discriminator

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-l2tpext-sbfd-discriminator-01.txt
Reviewer: Manav Bhatia
Review Date: 2015-12-31
IETF LC End Date: date-if-known
Intended Status: Proposed Standard (ID says Standards track)

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

I have issues in general readability of the draft. There were parts that were not very clear but that could also be because i am not very conversant with L2TP. 

Major Issues:

1. The document describes how one or more than one S-BFD descriminator can be advertised using L2TPv3 AVP. The draft when originally written was inline with the popular idea then, that a node MAY want to advertise more than one S-BFD descriminator. This idea however, is losing currency since the reason that necessitated this capability is now being questioned. Given this, the authors might need to rewrite sections of this draft, if the consensus is to remove the notion of advertising multiple discriminators.

Minor Issues:

1. Most of the acroynms have not been expanded and referenced.

2. The figure in the draft is not clear. I dont even want to guess how that needs to be interpreted.

Cheers, Manav
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Loa Andersson | 18 Dec 15:22 2015
Picon

rtg dir review of draft-ietf-l2tpext-sbfd-discriminator

  Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see ‚Äč 
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-l2tpext-sbfd-discriminator-01.txt
Reviewer: Loa Andersson
Review Date: 2015-12-18
IETF LC End Date: date-if-known
Intended Status: Proposed Standard (ID says Standards track)

Summary:

     I have some minor concerns about this document that I think should 
be resolved before publication.

Comments:

      I have considerable problems reading the draft, first it does not
really follow RFC 7322 in some important details, also the format figure
(as I understand it) is misleading. The document need a facelift.

Major Issues:

     "No major issues found."

Minor Issues:

     Even though the nit-picking below is pretty massive, it is purely
editorial and should be fixed before going to IETF Last Call. I have
no real concerns about the technical content

Abstract:
---------
     I used often "my immediate manager" as a reference and said that
the abstract should give her/him a good idea about what the draft is
about. I don't think the abstract meet that standard. Could you please
flesh out.

     RFC 7322 says that "Similarly, the Abstract should be complete
in itself.  It will appear in isolation in publication announcements
and in the online index of RFCs." If I encounter this and is not up to
speed on l2tp and bfd, this does not give a good idea what it is about.

Abbreviations

RFC 7322 says:
    Abbreviations should be expanded in document titles and upon first
    use in the document.  The full expansion of the text should be
    followed by the abbreviation itself in parentheses.  The exception is
    an abbreviation that is so common that the readership of RFCs can be
    expected to recognize it immediately; examples include (but are not
    limited to) TCP, IP, SNMP, and HTTP.  The online list of
    abbreviations [ABBR] provides guidance.  Some cases are marginal, and
    the RFC Editor will make the final judgment, weighing obscurity
    against complexity.

The abbreviations are not expanded in title, abstract, and some other
places, nor are they "well-known".

Examples
AVP - the RFC Editor abbreviation list gives two expansions, since this
is l2tp I come to the conclusion that this is "attribute-value pair" and
not the wellknow "Audio-Visual Profile (AVP)"

S-BFD - BFD is not well-known, and S-BFD is not even in the RFC Editors
abbreviations list.

L2TPv3 - L2TP or L2TPv3 are not well-know. There is no RFC that does
not expand the abbreviation in the title.

ICRQ, ICRP, OCRQ, and OCRP are sued but not expanded, the pointer to 
where to find the expansions (RFC 3931) are nit give until the third
time the quartet is mentioned

LCCE - used but not expanded. nor well-known.
The RFC Editor abbreviations has two expansions
LCCE       - Logical Cluster Computing Environment (LCCE) or
            - L2TP Control Connection Endpoint (RFCs 3931 and 4719)
Since this is is L2TP context, it is the latter that is correct, but
since we have an ambiguity we need to expand.

Section 2

I have a problem parsing this sentence:

    This AVP is exchanged during session negotiation (ICRQ, ICRP, OCRQ,
    OCRP).

Do you mean to say

    The "S-BFD Target Discriminator ID" AVP is exchanged using the ICRQ,
    ICRP, OCRQ, and OCRP control messages during session negotiations.

Section 2.1
    There is a TBD in the first sentence of this paragraph. While I
    agree that TDB is "well-know" I prefer using [TBA by IANA],
    where TBA stands for To Be Assigned.
    If you change this you also need to change in the IANA section.

Excuse me if I don't understand this figure

                                                      No. of octets
                  +-----------------------------+
                  | Discriminator Value(s)      |     4/Discriminator
                  :                             :
                  +-----------------------------+

First I think you say that a Discriminator is 4 octets
Second there can be a variable number of discriminators per attribute
value field
The box in your figure seems to 29 bits wide, this is unorthodox.

                   0       1       2       3
                   01234567012345670123456701234567
                  +-----------------------------+
                  | Discriminator Value(s)      |
                  :                             :
                  +-----------------------------+

Is this what you mean?

                   0       1       2       3
                   01234567012345670123456701234567
                  +--------------------------------+
                  | Discriminator Value (1)        |
                  +--------------------------------+
                  :                                :
                  +--------------------------------+
                  | Discriminator Value (n-1)      |
                  +--------------------------------+
                  | Discriminator Value (n)        |
                  +--------------------------------+

Discriminator - a 4 octet value

IANA consideration

      There is a practice - which I disagree with - to assume that IANA
and readers know where to the registries. Please point it out so no
mistakes are possible.

OLD TEXT
This number space is managed by IANA as per [RFC3438].

NEW TEXT
IANA maintain a sub-registry "Message Type AVP (Attribute Type 0)
Values" in the "Control Message Attribute Value Pairs" as per
[RFC3438]. IANA is requested to assign the first free value from this
sub-registry as the Message typ AVP for "S-BFD Discriminators".

Nits:

The nits tool does only give us the date warning.

/Loa

--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Ignacio Goyret | 8 Dec 14:52 2015

l2tpext-sbfd-discriminator comments

Hi authors,
Minor details, mostly for clarity or grammar:

1) Page 3, "Encoding format"
   a)
      BEFORE:
        The S-BFD Target Discriminator ID AVP, Attribute Type TBD, is an
                                                                   ^^^^^
        identifier used to advertise the S-BFD target discriminators
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        supported by an LCCE for S-BFD Reflector operation.

      AFTER:
        The S-BFD Target Discriminator ID AVP, Attribute Type TBD,
        advertises the S-BFD target discriminators
        ^^^^^^^^^^
        supported by an LCCE for S-BFD Reflector operation.

      OR: s/advertises/identifies/

   a) I believe it should be made more clear that each discriminator
      is 4 octets long. May be the drawing should be modified to show
      something like this:

     +------+------+------+------+
     |   Discriminator Value 1   |
     +------+------+------+------+
       .....
     +------+------+------+------+

     The text description should also include a more formal declaration of
     the AVP value, something like this:

       "The Attribute Value field of this AVP is a sequence of one or
        more S-BFD Discriminator values, each 4 octets long."

   b)
     BEFORE:
        ...discard this AVP without affecting the rest of session negotiation.

     AFTER:
        ...discard this AVP without affecting the rest of the session negotiation.
                                                          ^^^

   c) 
     BEFORE:
       the AVP encoding allows specification an
       arbitrary number of discrminators for extensibility.
                              ^^^^

     AFTER:
       the AVP encoding allows specification of an
                                            ^^^^
       arbitrary number of discriminators for extensibility.
                                ^

2) "Acknowledgements"

   BEFORE:
      performing thorough reviews and providing number of comments.

   AFTER:
      performing thorough reviews and providing a number of comments.
                                               ^^^
   OR:
      performing thorough reviews and providing numerous comments.
                                                ^^^^^^^^

-Ignacio
internet-drafts | 19 Nov 07:35 2015
Picon

I-D Action: draft-ietf-l2tpext-sbfd-discriminator-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

        Title           : Advertising S-BFD Discriminators in L2TPv3
        Authors         : Vengada Prasad Govindan
                          Carlos Pignataro
	Filename        : draft-ietf-l2tpext-sbfd-discriminator-01.txt
	Pages           : 5
	Date            : 2015-11-18

Abstract:
   This document defines a new AVP for advertising one or more S-BFD
   Discriminators using the L2TPv3 Control Protocol AVP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-sbfd-discriminator-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Ignacio Goyret | 19 Oct 18:39 2015

WGLC for draft-ietf-l2tpext-sbfd-discriminator

Hi group, 

This email starts a two-week Working-Group Last-Call (WGLC) for
draft-ietf-l2tpext-sbfd-discriminator-00
http://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

Please send comments to the list and state whether or not you support
progressing this document (in the later case, please also state the
reasons). Silence is not indication of support.

This poll runs until ** November 3rd, 2015 **.

We are also polling for knowledge of any IPR that applies to this
draft, 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 a document author or contributor *, please
respond only if you are aware of any changes to IPR from your
response during the poll for adoption, at http://www.ietf.org/mail-archive/web/l2tpext/current/msg01389.html

If you are *not* listed as an author or 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,

Carlos and Ignacio
L2tpext co-chairs
Alexander Vainshtein | 18 Sep 19:34 2015

RTG-DIR review: draft-ietf-l2tpext-keyed-ipv6-tunnel-05

Hello,

have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

 

Document: draft-ietf-l2tpext-keyed-ipv6-tunnel-05txt 
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 18-Sep-15
IETF LC End Date: Not Known 
Intended Status: Proposed Standard

 

Caveat:

I am not an IPv6 expert and this can be the reason for some of my concerns about the draft.

My experience with L2TPv3 is also outdated. So I’d like to ask the Routing ADs to take my comments with a big grain of salt.

 

Summary: 

I have one significant concern about this document and recommend that the Routing ADs discuss these issues further with the authors. I also have several minor concerns about the document that I think should be resolved before publication, and I have find a couple of nits.

 

Comments:

As I see it, the draft is built around three key ideas:

1.      IPv6 addresses, due to their unlimited availability, can be used to identify attachment circuits (or VSI forwarders)  of L2TPv3 sessions (and not just tunnel endpoints as in RFC 3931).

2.      With IPv6 addresses used for identifying L2 circuits or VSI) to be connected by L2TPv3 PWs, L2TPv3 Session ID processing in the data plane can be bypassed. I can guess that this really simplifies data plane handling and that this was the prime driver for the technology the draft defines, but this is just a guess.

3.      L2TPv3 sessions identified by IPv6 addresses can be used to provide operator-managed services that neither need nor use L2TPv3 control plane. The control plane functionality is moved to an external management entity that can access both endpoints of the service, sets the service up and continuously intervenes in its operation until it tears down the service.

 

The term “keyed IPv6 tunnel” refers to an L2TPv3 session that bypasses Session ID processing and relies on IPv6 addresses of its endpoints. Depending on the nature of emulated Ethernet service, these IPv6 addresses are used to identify either L2 attachment circuits for P2P services or Virtual Switching Instances (VSI) for MP2MP services.

 

Since L2TPv3 control plane is by design left out of scope of the draft, it mainly deals with the data plane. Additional information about the management plane aspects can be found in the YANG Data Model draft.

 

The draft is not easy to read and understand (at least to me), mainly because pieces of important information are often distributed throughout the text. One example illustrating this complaint:

·         The first sentence in Section 2 states that “Static local configuration creates a one-to-one mapping between the  access-side L2 attachment circuit and the IP address used in the network-side IPv6 encapsulation.  The L2TPv3 Control Plane defined in RFC3931 is not used”. This suggests(at least to me) that the management plane is involved just in setting up and tearing down a keyed IPv6 tunnel – similar to how static PWs over MPLS PSN are operated.

·         The catch comes with the last sentence of Section 3: “Cookie values SHOULD be changed periodically” thus indicating that continuous intervention of the management entity is expected for the entire life cycle of the service – something that strongly smells of Lifecycle Service Orchestration (LSO) to me, even if the term is never mentioned.

In the process of preparing this review I have sent my comments to the authors, to Carlos (the draft shepherd) and to Mark (who is listed as a contributing author). I have received very useful feedback  from them that has helped me to understand both the draft and the nature of our disagreements.  I would like to thank Giles, Rayner, Carlos and Mark for a very useful discussion, even if we did not reach an agreement on some of the points yet.

 

Major Issue:

Specification of encapsulation of Ethernet frames in Section 4 of the draft is incomplete and, to some extent, contradictory:

1.      L2TPv3 L2-specific sublayer  defined in RFC 3931 is not mentioned anywhere in the text.

2.      As the draft borrows encapsulation of Ethernet frames from RFC 4719, one could expect that its usage is OPTIONAL (same as in RFC 4719)

3.      On the other hand, L2-specific sublayer does not appear in the diagram depicting the encapsulation on page 5, so one could easily assume that it cannot be used with keyed IPv6 tunnels

4.      To add to this confusion, the draft mentions ability to use VCCV in a keyed IPv6 tunnel (Section 6, last para), and references RFC 5085. But this RFC, in Section 6.1 states that “In order to carry VCCV messages within an L2TPv3 session data packet, the PW MUST be established such that an L2-Specific Sublayer (L2SS) that defines the V-bit is present

From my POV the authors must clearly and unequivocally specify whether L2-specific sublayer can or cannot be used in keyed IPv6 tunnels. If they decide that it cannot be used, the references to VCCV must be removed from the draft.

I believe that this gap is acknowledged by the document shepherd and by one of the authors.

               Minor Issues:

1.      The draft does not explain the motivation for replacing the mechanism defined in RFC 4791 (which, AFAIK, was supposed to work equally well over IPv4 and IPv6). I can guess that bypassing processing of Session ID  simplifies the data plane processing, but this is just my guess. Some text explaining the benefits of keyed IPv6 tunnels in comparison with RFC 4719 would be most helpful IMO.

2.      To the best of my understanding, the technology defined in the draft heavily depends on availability of an external management entity that not only sets up and tears down the service (as is common with services that uses statically configured PWs, say, in MPLS-TP), but also intervenes in the operation of the service during its entire life cycle. However, the authors do not spell out their expectations from such an entity, the only exception being the need to periodically change the cookie values in a coordinated manner. I do not expect the draft to provide a detailed specification of such an entity, but I think that both the implementers and operators planning to deploy this technology would benefit from some additional information. In particular, the following aspects of behavior of the service that uses keyed IPv6 tunnels could be of special interest:

a.       What happens to a P2P service that uses a keyed IPv6 tunnel to connect two Ethernet L2 circuits if failure of one of these circuits is detected (e.g., using Ethernet service CFM  between the Down MEP at the tunnel endpoint and a matching MEP in the CE as defined in Section 6, the first bullet on page 8)? Is transmission across the IPv6 PSN at the other endpoint expected to be throttled by the management entity?

b.      The possibility to use an anycast address for identification of a keyed IPv6 tunnel endpoint is mentioned twice in the draft - in Section 2, 3rd para and in Section 4, first bullet on page 6. What happens if an anycast address assigned to one of the endpoints of a keyed IPv6 tunnel moves across the network? Is the management entity expected to handle these transitions, say, by de-activating the former endpoint associated with an anycast address and activating the new one?

c.       Is the management entity expected to emulate the PW redundancy mechanisms (defined in RFC 67180 and RFC 6870 for PWs over an MPLS PSN and in RFC 5641 for the PWs using L2TPv3? It should be noted that, in the case of MPLS PWs, PW redundancy switchover does not require involvement of a management entity even for statically configured PWs. Instead, static PW status messages (RFC 6478) are used

d.      The draft mentions the possibility to use keyed IPv6 tunnels to connect VSI participating in an MP2MP Ethernet service (even if the term VSI is never used). To me this implies that local FIB in each of the VSI connected over keyed IPv6 tunnels would use MAC learning to populate its local FIB. In order to speed up convergence of such services following various external events, RFC 4672 introduces a dedicated mechanism for MAC withdrawal, and the PALS WG currently holds a WG item extending this functionality for VPLS services that use static PWs. Is the management entity expected to provide similar functionality as well? (It should be noted that MAC withdrawal mechanisms have been defined as OPTIONAL in RFC 4762, but, AFAIK, they are widely implemented and deployed in the field).

3.      The draft mentions (in many places) that it expects consistent configuration of the endpoints of a keyed IPv6 tunnel. However, the draft (probably following a similar omission in RFC 4719) never mentions whether the management entity should prevent setting up a keyed IPv6 tunnel between a pair of endpoints with different MTU of L2 circuits. (This is a clear-cut requirement in RFC 4448 for Ethernet PWs over an MPLS PSN, and a parallel requirement for PWs over L2TPv3 can be found in RFC 4667).  A short statement and a reference to RFC 4667 (missing in RFC 4719) would suffice IMO,

4.      As mentioned before, the draft de-facto assigns IPv6 addresses to access-side L2 circuits that are not IP interfaces (the draft uses the term “mapping”, but I do not see any difference). The draft RECOMMENDS (in para 2 of Section 2) that “local IPv6 addresses identifying L2TPv3 tunnels are assigned from  dedicated subnets used only for such tunnel endpoints”. From my POV this requirement is vague and the readers could benefit from clarification of associated issues. Again, I do not expect a detailed specification, but I would like to see the some answers to the following naïve questions:

a.       Is  an IPv6 address identifying an endpoint of a keyed IPv6 tunnel that is associated with a L2 circuit expected to remain reachable if the L2 circuit to which it is associated fails?

b.      Are addresses (or subnets) used for identification of endpoints of keyed IPv6 tunnels expected to be exposed beyond the boundaries of the management domain controlled by the above-mentioned management entity? Could they appear in the public Internet routing tables?

5.      The draft says (Section 2, 3rd para) that “Certain deployment scenarios may require using a single IPv6 address (typically a globally routable unicast or anycast address assigned to a virtual interface) to identify a tunnel endpoint for multiple IPv6 L2TPv3 tunnels.  For such cases the tunnel encapsulating device  identifies each tunnel by a unique combination of local and remote    IPv6 addresses”. From my POV the readers would benefit from the following clarifications:

a.       What exactly “a globally routable address” means in this context?

b.      How, from the point of view of network reachability, are IPv6 addresses used in this scenario different from IPv6 addresses used to identify L2 circuits in other deployment scenarios?

c.       Since the text mentions identification of the tunnel by an “encapsulation device”, how is the tunnel identified by the decapsulating device? At least from the POV of MAC learning in the case of keyed IPv6 tunnels connecting VSI, identification of the tunnel by the decapsulating device seems more relevant to me

d.      How should the device  know whether a specific keyed IPv6 tunnel can be identified by just one IPv6 address or by a “a unique combination of local and remote    IPv6 addresses”?

6.      As I have mentioned above, some details pertaining to the management functionality associated with keyed IPv6 tunnels are defined in another L2TPEXT WG draft, but this draft is not mentioned in the draft I am reviewingI think that an Informative reference to this draft would be very much in place in this one.

7.      I wonder whether an Informative reference to a long (13-Jan-1999 according to the Datatracker) expired draft of a concluded WG in the last sentence on page 3 has any value for the reader. If the ideas of this draft have found their way to some RFC, it should be used as a reference instead; otherwise I believe that this reference cold be safely removed.

 

Some of the issues I have raised could be addressed in a suitable Applicability Statement section, but there are clearly other ways to handle them.

 

Nits:

I (or, rather, my spellchecker) has found two typos:

·         Section 2, para 2: s/endponts/endpoints/

·         Section 5, para 3 on page 7:  s/Fragmention/Fragmentation/

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein <at> ecitele.com

 

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Vinay Kumar Tripathi | 16 Sep 14:08 2015

Test Mail

Hi All,

Sending this mail to verify my subscription.
Apologies for the spam.

thanks
Vinay
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Ignacio Goyret | 14 Jul 20:57 2015

Re: Call for adoption: draft-sun-l2tpext-keyed-v6-tunnel-yang

Thanks for the update.

We can now officially adopt the document. Unfortunately, we have to wait
until after the meeting to submit a WG -00 document.
I'll be looking for it.

-Ignacio

At 00:05 7/14/2015, ian.farrer <at> telekom.de wrote:
>Hi Ignacio,
>
>My apologies for missing this. There is no IPR from my side.
>
>Regards,
>Ian
>
>-----Original Message-----
>From: Ignacio Goyret [mailto:i.goyret <at> alcatel-lucent.com] 
>Sent: 14 July 2015 03:11
>To: Farrer, Ian
>Cc: l2tpext <at> ietf.org
>Subject: Re: [L2tpext] Call for adoption: draft-sun-l2tpext-keyed-v6-tunnel-yang
>Importance: High
>
>Ian,
>Just a reminder that there is no statement from you regarding IPR yet.
>I need your statement before I can advance this document further.
>-Ignacio
>
>
>At 11:41 6/8/2015, Ignacio Goyret wrote:
>>Hello working group,
>>
>>This email starts a two-week poll on adopting 
>>draft-sun-l2tpext-keyed-v6-tunnel-yang [1] as a working group item.
>>
>>Please send comments to the list and state if you support adoption or 
>>not (in the later case, please also state the reasons).
>>
>>This poll runs until ** June 22nd, 2015 **.
>>
>>
>>We are also polling for knowledge of any IPR that applies to this 
>>draft, 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 a document author or contributor *, please 
>>respond to this email and indicate whether or not you are aware of any 
>>relevant IPR.
>>
>>The draft will not be adopted until a response has been received from 
>>each author and contributor.
>>
>>If you are not listed as an author or 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,
>>
>>Ignacio Goyret / Carlos Pignataro
>>l2tpext chairs
>>
>>[1] 
>>http://datatracker.ietf.org/doc/draft-sun-l2tpext-keyed-v6-tunnel-yang/
>>
>>_______________________________________________
>>L2tpext mailing list
>>L2tpext <at> ietf.org
>>https://www.ietf.org/mailman/listinfo/l2tpext
>
>_______________________________________________
>L2tpext mailing list
>L2tpext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/l2tpext
internet-drafts | 6 Jul 23:29 2015
Picon

I-D Action: draft-sun-l2tpext-keyed-v6-tunnel-yang-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

        Title           : A YANG Data Model for Keyed IPv6 Tunnels
        Authors         : Qi Sun
                          Ian Farrer
                          Bing Liu
                          Giles Heron
	Filename        : draft-sun-l2tpext-keyed-v6-tunnel-yang-01.txt
	Pages           : 14
	Date            : 2015-07-06

Abstract:
   This document defines a YANG data model for the configuration and
   management of Keyed IPv6 tunnels.  The data model includes
   configuration data and state data.  Due to the stateless nature of
   keyed IPv6 tunnels, a model for NETCONF notifications is not
   necessary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-sun-l2tpext-keyed-v6-tunnel-yang/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-sun-l2tpext-keyed-v6-tunnel-yang-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-sun-l2tpext-keyed-v6-tunnel-yang-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Gmane