Re: [RTG-DIR] rtg dir review of draft-ietf-l2tpext-sbfd-discriminator

--===============2696368156746277182==
Content-Language: en-US
Content-Type: multipart/signed;
 boundary="Apple-Mail=_59854B38-5F80-49E1-812D-19DAF7B84FDA";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Apple-Mail=_59854B38-5F80-49E1-812D-19DAF7B84FDA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Good catch!

ICCN/OCCN should not be included. Fixed.

=E2=80=94 Carlos.

> On Dec 19, 2015, at 12:54 AM, Loa Andersson <[email protected]> wrote:
>=20
> Deborah, authors,
>=20
> I found one more small glitch.
>=20
> At most place the document says that the "S-BFD Target Discriminator
> ID" AVP goes with ICRQ, ICRP, OCRQ, and OCRP.
>=20
> But section 2.1. includes ICCN also.
>=20
> /Loa
>=20
> On 2015-12-18 22:22, Loa Andersson wrote:
>>  Hello,
>>=20
>> I have been selected as the Routing Directorate reviewer for this =
draft.
>> The Routing Directorate seeks to review all routing or =
routing-related
>> drafts as they pass through IETF last call and IESG review, and
>> sometimes on special request. The purpose of the review is to provide
>> assistance to the Routing ADs. For more information about the Routing
>> Directorate, please see =E2=80=8B
>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>=20
>> Although these comments are primarily for the use of the Routing ADs, =
it
>> would be helpful if you could consider them along with any other IETF
>> Last Call comments that you receive, and strive to resolve them =
through
>> discussion or by updating the draft.
>>=20
>> Document: draft-ietf-l2tpext-sbfd-discriminator-01.txt
>> Reviewer: Loa Andersson
>> Review Date: 2015-12-18
>> IETF LC End Date: date-if-known
>> Intended Status: Proposed Standard (ID says Standards track)
>>=20
>> Summary:
>>=20
>>     I have some minor concerns about this document that I think =
should
>> be resolved before publication.
>>=20
>> Comments:
>>=20
>>      I have considerable problems reading the draft, first it does =
not
>> really follow RFC 7322 in some important details, also the format =
figure
>> (as I understand it) is misleading. The document need a facelift.
>>=20
>>=20
>>=20
>> Major Issues:
>>=20
>>     "No major issues found."
>>=20
>> Minor Issues:
>>=20
>>     Even though the nit-picking below is pretty massive, it is purely
>> editorial and should be fixed before going to IETF Last Call. I have
>> no real concerns about the technical content
>>=20
>> Abstract:
>> ---------
>>     I used often "my immediate manager" as a reference and said that
>> the abstract should give her/him a good idea about what the draft is
>> about. I don't think the abstract meet that standard. Could you =
please
>> flesh out.
>>=20
>>     RFC 7322 says that "Similarly, the Abstract should be complete
>> in itself.  It will appear in isolation in publication announcements
>> and in the online index of RFCs." If I encounter this and is not up =
to
>> speed on l2tp and bfd, this does not give a good idea what it is =
about.
>>=20
>> Abbreviations
>>=20
>> RFC 7322 says:
>>    Abbreviations should be expanded in document titles and upon first
>>    use in the document.  The full expansion of the text should be
>>    followed by the abbreviation itself in parentheses.  The exception =
is
>>    an abbreviation that is so common that the readership of RFCs can =
be
>>    expected to recognize it immediately; examples include (but are =
not
>>    limited to) TCP, IP, SNMP, and HTTP.  The online list of
>>    abbreviations [ABBR] provides guidance.  Some cases are marginal, =
and
>>    the RFC Editor will make the final judgment, weighing obscurity
>>    against complexity.
>>=20
>> The abbreviations are not expanded in title, abstract, and some other
>> places, nor are they "well-known".
>>=20
>> Examples
>> AVP - the RFC Editor abbreviation list gives two expansions, since =
this
>> is l2tp I come to the conclusion that this is "attribute-value pair" =
and
>> not the wellknow "Audio-Visual Profile (AVP)"
>>=20
>> S-BFD - BFD is not well-known, and S-BFD is not even in the RFC =
Editors
>> abbreviations list.
>>=20
>> L2TPv3 - L2TP or L2TPv3 are not well-know. There is no RFC that does
>> not expand the abbreviation in the title.
>>=20
>> ICRQ, ICRP, OCRQ, and OCRP are sued but not expanded, the pointer to
>> where to find the expansions (RFC 3931) are nit give until the third
>> time the quartet is mentioned
>>=20
>> LCCE - used but not expanded. nor well-known.
>> The RFC Editor abbreviations has two expansions
>> LCCE       - Logical Cluster Computing Environment (LCCE) or
>>            - L2TP Control Connection Endpoint (RFCs 3931 and 4719)
>> Since this is is L2TP context, it is the latter that is correct, but
>> since we have an ambiguity we need to expand.
>>=20
>> Section 2
>>=20
>> I have a problem parsing this sentence:
>>=20
>>    This AVP is exchanged during session negotiation (ICRQ, ICRP, =
OCRQ,
>>    OCRP).
>>=20
>> Do you mean to say
>>=20
>>    The "S-BFD Target Discriminator ID" AVP is exchanged using the =
ICRQ,
>>    ICRP, OCRQ, and OCRP control messages during session negotiations.
>>=20
>> Section 2.1
>>    There is a TBD in the first sentence of this paragraph. While I
>>    agree that TDB is "well-know" I prefer using [TBA by IANA],
>>    where TBA stands for To Be Assigned.
>>    If you change this you also need to change in the IANA section.
>>=20
>> Excuse me if I don't understand this figure
>>=20
>>                                                      No. of octets
>>                  +-----------------------------+
>>                  | Discriminator Value(s)      |     4/Discriminator
>>                  :                             :
>>                  +-----------------------------+
>>=20
>> First I think you say that a Discriminator is 4 octets
>> Second there can be a variable number of discriminators per attribute
>> value field
>> The box in your figure seems to 29 bits wide, this is unorthodox.
>>=20
>>=20
>>                   0       1       2       3
>>                   01234567012345670123456701234567
>>                  +-----------------------------+
>>                  | Discriminator Value(s)      |
>>                  :                             :
>>                  +-----------------------------+
>>=20
>> Is this what you mean?
>>=20
>>                   0       1       2       3
>>                   01234567012345670123456701234567
>>                  +--------------------------------+
>>                  | Discriminator Value (1)        |
>>                  +--------------------------------+
>>                  :                                :
>>                  +--------------------------------+
>>                  | Discriminator Value (n-1)      |
>>                  +--------------------------------+
>>                  | Discriminator Value (n)        |
>>                  +--------------------------------+
>>=20
>> Discriminator - a 4 octet value
>>=20
>> IANA consideration
>>=20
>>      There is a practice - which I disagree with - to assume that =
IANA
>> and readers know where to the registries. Please point it out so no
>> mistakes are possible.
>>=20
>> OLD TEXT
>> This number space is managed by IANA as per [RFC3438].
>>=20
>> NEW TEXT
>> IANA maintain a sub-registry "Message Type AVP (Attribute Type 0)
>> Values" in the "Control Message Attribute Value Pairs" as per
>> [RFC3438]. IANA is requested to assign the first free value from this
>> sub-registry as the Message typ AVP for "S-BFD Discriminators".
>>=20
>>=20
>> Nits:
>>=20
>> The nits tool does only give us the date warning.
>>=20
>> /Loa
>>=20
>>=20
>>=20


--Apple-Mail=_59854B38-5F80-49E1-812D-19DAF7B84FDA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWiRo4AAoJEIXgpQGOZny97qQP+wYal0T+AK9jcWH/UQfmI5Q/
6RdW/4RR6bYG/AlV5oLEH78J6a+WhM+bqQRgouEGSkwEjJiShO9np9WJRMVKFZi2
XxMDQqMyv0bmXxuwl3EkyLSRY4kJpiEqdoIg2mGhxfeHPOLH8luvVD+C1GoI3CsQ
irP0ieqDsZ//j9Vc7xkgnjZM3XeUfNMwZVUegiAOTrqn9gvGKelWqF+If274hRZZ
QDHdvrpq9Olc5N6wEQ+7kWlD5glWLt/F3ZE6mTifOxccbIFii8feVwTGp+naGaX5
tNVetkwsZMEylf1JT3nzg1dTnDhbz89z3v+uUQH/Xi8E69QFHzZaKumbJqSMxlIu
lxV2Ydq1QB+/xMcg2vxtKHfiJ0jWsIKlkyLYXz8lo02o7XH+fPyCPu+Mn3EZKzYj
QfM7MjZ/4DIyX6wkkmGONBS0I1PtQ9GVQwFWB3qFKx2LQHwwfhO2tjxb4wtNf8I1
4LMDuXAI/GW3jEZgOdLDOnolADnQXKyPOGymomn6FLXhSQFxP4nF8zyL5/T82gPd
cvUA+fRoP8iZcnjPxc8CfEoWu6XB5ECLDjUjTCrGcmFx4jXAfk49LkcC0+/f5xb4
/tHhKVM1WLCsV58QGXE9QgBoMyblduCYTWyQji935FDAu6WSjndq7dyaYsyhe7lr
/iCxyXZPFfrCvB+BZ0Ek
=vsvt
-----END PGP SIGNATURE-----

--Apple-Mail=_59854B38-5F80-49E1-812D-19DAF7B84FDA--


--===============2696368156746277182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext

--===============2696368156746277182==--