Subject: [Gen-art] Gen-ART LC review of draft-thaler-v6ops-teredo-extensions-07

From: "Roni Even" <[email-masked]>
Date: Wed, 4 Aug 2010 10:44:44 +0300

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-thaler-v6ops-teredo-extensions-07

Reviewer: Roni Even

Review Date: August 4, 2010

IETF LC End Date: 2010-08-12

IESG Telechat date: (if known)

Summary: This draft is roughly ready for publication as a Proposed Standard.

I have some comments:

Major issues: None

Minor issues: 

1.  In section 4.1 defines type-length-value (TLV) encoded trailers. Can new
trailers be defined later and if yes what is the procedure to do it and
assign type numbers. If new trailers are not allowed it will be good to
state it also.

2.  In section 5.6.4.1 it says that "the Alternate Address Trailer MUST
include the node's local address/port in the Alternate Address/Port list.
If the UPnP Mapped Address/Port is non-zero, the Alternate Address Trailer
MUST also include it in the list." I understood from 3.5 and 6.5 that UPnP
support on the NAT is required in which case the alternate address trailer
must have a UPnP address or is the requirement for UPnP is needed only when
the two peers are connected via more than one NAT in the private address
space as section 3.5 and 6.5 describe. Please clarify.

Nits/editorial comments: none

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Aug 2010 00:48:27 -0400

Thanks for your review, Roni.

> 1. In section 4.1 defines type-length-value (TLV) encoded trailers. 
> Can new trailers be defined later and if yes what is the procedure to 
> do it and assign type numbers. If new trailers are not allowed it will 
> be good to state it also
>

There has been earlier discussion on this. I wrote in my AD review:

> 8.  IANA Considerations
>  
>     [RFC Editor: please remove this section prior to publication.]
>  
>     This document has no IANA Actions.
>  
>  I do not understand how this can be. The document introduces new formats and
>  new fields, e.g., DiscoveryType field in Section 4.4. How are new values
>  allocated?

Dave responded:

> No change.  The new fields are not delegated to IANA to maintain, they're
> simply defined in this document and hence can only be updated by future
> RFC action that Updates this document.  In this sense, they're no different 
> from how, say, the flags bits in IPv6 RA's are allocated.

and I replied:

> I'm fine with no IANA actions, but then you should at least state in 
> the draft what you stated in the e-mail. In any case, that is a small 
> thing that we can deal with later. 

In other words, I believe the document still needs a change to describe what the procedure is to extend the TLVs. Dave?

> 2. In section 5.6.4.1 it says that “the Alternate Address Trailer MUST 
> include the node's local address/port in the Alternate Address/Port 
> list. If the UPnP Mapped Address/Port is non-zero, the Alternate 
> Address Trailer MUST also include it in the list.” I understood from 
> 3.5 and 6.5 that UPnP support on the NAT is required in which case the 
> alternate address trailer must have a UPnP address or is the 
> requirement for UPnP is needed only when the two peers are connected 
> via more than one NAT in the private address space as section 3.5 and 
> 6.5 describe. Please clarify.
>

Good question. I can't answer it, Dave?

Jari