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). 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? 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. I think the IANA Considerations lack precision, but I assume IANA will review that.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
