Genart last call review of draft-ietf-softwire-map-radius-23

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-softwire-map-radius-??
Reviewer: Joel Halpern
Review Date: 2019-05-17
IETF LC End Date: 2019-05-31
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:
    Figure 1 of section 3.1.1 and section 3.1.1.3 do not match.   It appears
    from later text that the problem is simple.  Figure 3.1.1 needs to include,
    in the portion for the Softwire46-Lightweight-4over6 Attribute, the fact
    that the Softwire46-BR attribute is permitted there.  Particularly since it
    is required. Section 3.1.4.1 states that the IPv6 prefix is 128 bits.  It
    also points to RFC 8044 section 3.10.  Section 3.10 is quite clear that in
    order to include the prefix length, the TLV may be longer that 128 bits.
    (Section 3.1.5.2 correctly uses the ipv6pref type.) Thus, it also appears
    that the stated TLV length is wrong.
     Section 3.1.4.2 states that the IPv4 prefix is 32 bits.  It also points to
     RFC 8044 section 3.11.  Section 3.11 states that the TLV is 48 bits. 
     Thus, it also appears that the stated TLV length is wrong.

Minor issues:
    I trust that the WG Chairs and document shepherd will work with the authors
    to reduce the number of front page authors?  I looked in the shepherd
    writeup to see if there was an explanation of the large number of authors,
    but did not see one.

    Section 3.1 states that the Softwire46-Configuration Attribute may appear
    in an Access Request message.  Unlike the later material on multicast,
    there is no further explanation here of why it might appear, and how it
    should be processed if it does appear.  It would seem sensible to include
    this material.

Nits/editorial comments:
    In the description of the entries in table 2 (in section 3.1.2) should the
    entry for "1" read "1 Mandatory, may occur only once" rather than simply
    "Mandatory"?





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux