Re: Gen-ART LC review of draft-thaler-v6ops-teredo-extensions-07

[Jari Arkko <[e-mail]>]

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