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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf