Subject: [Gen-art] Gen-ART LC review of draft-ietf-softwire-encaps-safi-03.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Dec 2008 09:41:22 +1300

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Fri, 12 Dec 2008 10:34:17 -0800

Thank you for the detailed review and comments. Please see inline for
our responses.

We plan to post a new revision -04 of the draft when we close on
these.

| I have been selected as the General Area Review Team (Gen-ART)
reviewer
| for this draft (for background on Gen-ART, please see
| http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
| Please resolve these comments along with any other Last Call comments
| you may receive.
| Document: draft-ietf-softwire-encaps-safi-03.txt
| Reviewer: Brian Carpenter
| Review Date: 2008-12-07
| IETF LC End Date: 2008-12-15
| IESG Telechat date: (if known)
| 
| Summary: Almost ready
| 
| Comments: 
| 
| Substantive:
| 
| > 4. Tunnel Encapsulation Attribute
| ...
| >    Tunnel Type (2 octets): It identifies the type of the tunneling
| >    technology being signaled. This document defines the following
types:
| >
| >      - L2TPv3 over IP [RFC3931]: Tunnel Type = 1
| >
| >      - GRE [RFC2784]: Tunnel Type = 2
| 
| How is simple IP-in-IP encapsulation (e.g. RFC4213) identified?
| It's mentioned in the Introduction so there should be a type for it.
| 
| BTW, note that draft-ietf-mext-nemo-v4traversal has a similar 
| signaling issue, but chose Type = 1 for GRE (and also forgot to define
| a type for IP-in-IP). 

Yes, we will add a Tunnel Type for IP-in-IP. The following is the
revised text. Tunnel types [3-6] are already defined in
draft-ietf-softwire-encaps-ipsec.

=============
   Tunnel Type (2 octets): It identifies the type of the tunneling
   technology being signaled. This document defines the following types:

     - L2TPv3 over IP [RFC3931]: Tunnel Type = 1

     - GRE [RFC2784]: Tunnel Type = 2

     - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7
=============

| I don't see why [Softwires-Mesh-Frame-work] is a normative reference,
| and making it informational would avoid a publication deadlock.
| 
| Having [IANA-AF] as a normative reference also seems odd. Of course
| IANA-assigned values must be used, but we don't commonly use
registries
| as normative references, do we?

Agree. Will move these two to the Informative section in the next
revision.

| 
| Editorial:
| 
| The Abstract seems a bit long to me. I would suggest shortening it
| during editing. Most of the second paragraph seems to fit better as
| the start of the Introduction.

Would prefer to leave the abstract as is unless you strongly
disagree so that a precise definition of what the draft contains is
known by reading the abstract.

| I think the IANA Considerations lack precision, but I assume IANA
| will review that.

Yes. We are thinking of changing the IANA Considerations section to
the following (though one round of review by IANA just occurred):

=============
   IANA shall assign a value from the "Subsequent Address Family"
   Registry, in the "Standards Action" range, to be called
   "Encapsulation SAFI", with this document as the reference.

   IANA shall assign a value from the "BGP Path Attributes" Registry, to
   be called "Tunnel Encapsulation Attribute", with this document as the
   reference.

   IANA shall assign two new values from the "BGP Opaque Extended
   Community" type Registry.  Both are from the transitive range.  The
   first new value is called "Color Extended Community", and the second
   is called "Encapsulation Extended Community".  This document is the
   reference for both assignments.

   IANA shall set up a registry for "BGP Tunnel Encapsulation Attribute
   Tunnel Types".  This is a registry of two-octet values (0-65535), to
   be assigned on a first-come, first-serve basis.  The initial
   assignments shall be as follows:

      Tunnel Name                             Type
      ---------------                         -----
      L2TPv3 over IP                            1
      GRE                                       2
      IP in IP                                  7

   IANA  shall set  up a  registry for  "BGP Tunnel  Encapsulation
   Attribute Sub-TLVs".   This  is a  registry  of  one-octet  values
   (0-255),  to  be assigned on  a "standards action/early allocation"
   basis.  This document is the reference.  The initial assignments are:

      Sub-TLV name                            Type
      -------------                           -----
      Encapsulation                             1
      Protocol type                             2
      Color                                     4
=============

Let us know your comments and we can post the revised document as
-04.

- Pradosh

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Dec 2008 16:13:10 +1300

Hmm. I never saw that message, although it is in the gen-art
list archive. I've restored the various cc's in this reply.

Yes, these changes look fine to me. Thanks!

    Brian

On 2008-12-17 12:12, Pradosh Mohapatra (pmohapat) wrote:
> Hi Brian,
> 
> Following up...
> 
> Do you have any specific comments on the responses or should we
> go ahead with posting the -04 version?
> 
> - Pradosh
> 
> | -----Original Message-----
> | From: Pradosh Mohapatra (pmohapat) 
> | Sent: Friday, December 12, 2008 10:34 AM
> | To: 'Brian E Carpenter'; General Area Review Team
> | Cc: [email-masked]; 
> | [email-masked]; Mark Townsley 
> | (townsley)
> | Subject: RE: Gen-ART LC review of 
> | draft-ietf-softwire-encaps-safi-03.txt
> | 
> | Thank you for the detailed review and comments. Please see 
> | inline for our responses.
> | 
> | We plan to post a new revision -04 of the draft when we close 
> | on these.
> | 
> | | I have been selected as the General Area Review Team (Gen-ART) 
> | | reviewer for this draft (for background on Gen-ART, please see 
> | | http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> | | Please resolve these comments along with any other Last 
> | Call comments 
> | | you may receive.
> | | Document: draft-ietf-softwire-encaps-safi-03.txt
> | | Reviewer: Brian Carpenter
> | | Review Date: 2008-12-07
> | | IETF LC End Date: 2008-12-15
> | | IESG Telechat date: (if known)
> | | 
> | | Summary: Almost ready
> | | 
> | | Comments: 
> | | 
> | | Substantive:
> | | 
> | | > 4. Tunnel Encapsulation Attribute
> | | ...
> | | >    Tunnel Type (2 octets): It identifies the type of the tunneling
> | | >    technology being signaled. This document defines the 
> | following types:
> | | >
> | | >      - L2TPv3 over IP [RFC3931]: Tunnel Type = 1
> | | >
> | | >      - GRE [RFC2784]: Tunnel Type = 2
> | | 
> | | How is simple IP-in-IP encapsulation (e.g. RFC4213) identified?
> | | It's mentioned in the Introduction so there should be a type for it.
> | | 
> | | BTW, note that draft-ietf-mext-nemo-v4traversal has a similar 
> | | signaling issue, but chose Type = 1 for GRE (and also 
> | forgot to define 
> | | a type for IP-in-IP).
> | 
> | 
> | Yes, we will add a Tunnel Type for IP-in-IP. The following is 
> | the revised text. Tunnel types [3-6] are already defined in 
> | draft-ietf-softwire-encaps-ipsec.
> | 
> | =============
> |    Tunnel Type (2 octets): It identifies the type of the tunneling
> |    technology being signaled. This document defines the 
> | following types:
> | 
> |      - L2TPv3 over IP [RFC3931]: Tunnel Type = 1
> | 
> |      - GRE [RFC2784]: Tunnel Type = 2
> | 
> |      - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7 =============
> | 
> | | I don't see why [Softwires-Mesh-Frame-work] is a normative 
> | reference, 
> | | and making it informational would avoid a publication deadlock.
> | | 
> | | Having [IANA-AF] as a normative reference also seems odd. Of course 
> | | IANA-assigned values must be used, but we don't commonly use 
> | | registries as normative references, do we?
> | 
> | Agree. Will move these two to the Informative section in the 
> | next revision.
> | 
> | | 
> | | Editorial:
> | | 
> | | The Abstract seems a bit long to me. I would suggest shortening it 
> | | during editing. Most of the second paragraph seems to fit better as 
> | | the start of the Introduction.
> | 
> | 
> | Would prefer to leave the abstract as is unless you strongly 
> | disagree so that a precise definition of what the draft 
> | contains is known by reading the abstract.
> | 
> | 
> | | I think the IANA Considerations lack precision, but I 
> | assume IANA will 
> | | review that.
> | 
> | 
> | Yes. We are thinking of changing the IANA Considerations 
> | section to the following (though one round of review by IANA 
> | just occurred):
> | 
> | =============
> |    IANA shall assign a value from the "Subsequent Address Family"
> |    Registry, in the "Standards Action" range, to be called
> |    "Encapsulation SAFI", with this document as the reference.
> | 
> |    IANA shall assign a value from the "BGP Path Attributes" 
> | Registry, to
> |    be called "Tunnel Encapsulation Attribute", with this 
> | document as the
> |    reference.
> | 
> |    IANA shall assign two new values from the "BGP Opaque Extended
> |    Community" type Registry.  Both are from the transitive range.  The
> |    first new value is called "Color Extended Community", and 
> | the second
> |    is called "Encapsulation Extended Community".  This document is the
> |    reference for both assignments.
> | 
> |    IANA shall set up a registry for "BGP Tunnel Encapsulation 
> | Attribute
> |    Tunnel Types".  This is a registry of two-octet values 
> | (0-65535), to
> |    be assigned on a first-come, first-serve basis.  The initial
> |    assignments shall be as follows:
> | 
> |       Tunnel Name                             Type
> |       ---------------                         -----
> |       L2TPv3 over IP                            1
> |       GRE                                       2
> |       IP in IP                                  7
> | 
> |    IANA  shall set  up a  registry for  "BGP Tunnel  Encapsulation
> |    Attribute Sub-TLVs".   This  is a  registry  of  one-octet  values
> |    (0-255),  to  be assigned on  a "standards action/early allocation"
> |    basis.  This document is the reference.  The initial 
> | assignments are:
> | 
> |       Sub-TLV name                            Type
> |       -------------                           -----
> |       Encapsulation                             1
> |       Protocol type                             2
> |       Color                                     4
> | =============
> | 
> | Let us know your comments and we can post the revised document as -04.
> | 
> | - Pradosh
>