Re: [Softwires] intdir Telechat Review requested: draft-ietf-softwire-map-radius

["Bernie Volz (volz)" <[e-mail]>]

I am an assigned INT directorate reviewer for draft-ietf-softwire-map-radius-22. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/.

This draft looks pretty good but there are a few quickly fixed issues and a bunch of minor nits. But, otherwise the draft looks ready to move forward.

Issues:

Section 3.1.3.1

I think the following text is in error:
   Defining multiple TLV-types achieves the same design goals as the
   "Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598].  Using
   TLV-type set to 4 is equivalent to setting the F-flag in the
   OPTION_S46_RULE S46 Rule Flags field.
It should say (s/ 4 / 5 /):
   Defining multiple TLV-types achieves the same design goals as the
   "Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598].  Using
   TLV-type set to 5 is equivalent to setting the F-flag in the
   OPTION_S46_RULE S46 Rule Flags field.
(I assume that "setting the F-flag" means setting it to 1.)

I'm also not sure what the following means:
	     5 Forwarding Permitted Mapping Rule (may be used for
	        forwarding. Can also be a Basic Mapping Rule)
Shouldn't this just be:
	     5 Forwarding Permitted Mapping Rule

FYI - The text in RFC7598 is:
   o  F-flag: 1-bit field that specifies whether the rule is to be used
      for forwarding (FMR).  If set, this rule is used as an FMR; if not
      set, this rule is a BMR only and MUST NOT be used for forwarding.
      Note: A BMR can also be used as an FMR for forwarding if the
      F-flag is set.  The BMR is determined by a longest-prefix match of
      the Rule IPv6 prefix against the End-user IPv6 prefix(es).

Section 5:
The "CoA-Request" message is not mentioned in this table, but was mentioned in 3.1:
      The Softwire46-Configuration Attribute MAY appear in a CoA-Request
      packet.
It may also be appropriate to include a table number/title?


Minor Nits:

Section 3.1:
	s/ efer / refer /

Section 3.1.2:
	Remove the 0+ definition under Table 2 as it is not used and therefore not needed.

Section 3.2:
	s/ orderd / ordered /
	s/ attribute include one or / attributes includes one or /		(use includes)

Section 3.3: Suggestion
	It may be more consistent and shorter to combine "MAY appear", "MAY contain" rules? For example:

      The Softwire46-Multicast Attribute MAY appear in an Access-Request,
      Access-Accept, CoA-Request, and Accounting-Request packet.

      The Softwire46-Multicast Attribute MAY contain ASM-Prefix64 (see
      Section 3.3.1), SSM-Prefix64 (see Section 3.3.2), and U-Prefix64 (see
      Section 3.3.3) attributes.

Section 4:
	In 4, s/Theses are/These are/
	In 5, s/CE send a/CE sends a/

Appendix A.7:
	The "TLV Field" column is a bit odd since these are really subfields from RFC8044.
	So, rename "TLV Subfield"? And, the fields are "Prefix-Length" and "Prefix" from
	the TLV attribute.

- Bernie

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: Tuesday, April 23, 2019 1:20 PM
To: Bernie Volz (volz) <[e-mail]>; Carlos Bernardos <[e-mail]>
Subject: intdir Telechat Review requested: draft-ietf-softwire-map-radius


Telechat review of: draft-ietf-softwire-map-radius (no specific version)
Deadline: 2019-05-15
Requested by: Éric Vyncke

https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/reviewrequest/11924/login/

intdir Telechat Review requested: draft-ietf-softwire-map-radius