Subject: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09

From: "Roni Even" <[email-masked]>
Date: Tue, 24 May 2011 11:11:48 +0300

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-mpls-lsp-ping-enhanced-dsmap-09

Reviewer: Roni Even

Review Date:2011-5-24

IETF LC End Date: 2011-5-30

IESG Telechat date:

Summary: This draft is ready for publication as a standard track RFC.

Major issues:

Minor issues:

Nits/editorial comments:

1.       Need to expand LDP when first mentioned.

2.       Section 3.3.1.1 "The multipath data sub-TLV includes information
multipath information" delete the first information.

3.       In section 3.3.1.2 "When the Downstream Detailed Mapping TLV in
sent in the echo response" should be is sent.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 May 2011 11:15:44 +0100

Thanks Roni,

> 1. Need to expand LDP when first mentioned.

LDP is a recognised acronym at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt and does not need
to be expanded.

Cheers,
Adrian

---

From: Doug Barton <[email-masked]>
Date: Tue, 24 May 2011 11:11:20 -0700

> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt  and does not need

And how would someone new to the RFC series know that? :)

IMO one should always expand acronyms the first time they are used. It 
adds clarity to the text for new readers, and even for old hands it's 
sometimes necessary to disambiguate recycled TLAs.

Doug (three-letter acroynms)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 May 2011 19:33:20 +0100

Gotta draw a line somewhere, Doug.

(RFC? IMO? IETF?)

The RFC Editor draws that line for us. The list at the page I referenced is
constructed by the RFC Editor based on input from the community. I'm guessing
things can be deleted as well as added.

A  (stands for Adrian)

> -----Original Message-----
> From: Doug Barton [mailto:[email-masked]]
> Sent: 24 May 2011 19:11
> To: [email-masked]
> Cc: 'Roni Even'; [email-masked];
gen-
> [email-masked]; 'IETF-Discussion list'
> Subject: Re: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 24 May 2011 22:31:08 +0300

Hi Adrian,
This is up to you reading the abbrev.expansion.txt  I noticed that "Some
abbreviations are so well known that expansion is probably
unnecessary.  The RFC Editor exercises editorial judgment about whether a
particular use of one of the "well-known" abbreviations requires
expansion."

So it will be up to the RFC editor.

At least for me as a reader who is not familiar with all the abbreviations
in the draft I found that even if they are expanded on the first usage it
will be easier if all abbreviations are in one place in the document, but
this may be a separate discussion on general draft structure.

As for the  abbrev.expansion.txt, it does  not help since there is no
reference to it in draft-ietf-mpls-lsp-ping-enhanced-dsmap and as mentioned
some abbreviations have multiple expansions even in the RFC editor list
(e.g. FEC).

Roni

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2011 1:16 PM
> To: 'Roni Even'; draft-ietf-mpls-lsp-ping-enhanced-
> [email-masked]
> Cc: [email-masked]; 'IETF-Discussion list'
> Subject: RE: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-
> dsmap-09
> 
> Thanks Roni,
> 
> > Nits/editorial comments:
> >

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 24 May 2011 09:19:19 -0700

Thanks. I will take care of nits 2 & 3 in the next update. Will be ignoring nit #1, as per Adrian's comment.

Nitin

On 5/24/11 1:11 AM, "Roni Even" <[email-masked]> wrote:

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive.

Major issues:

Minor issues:

Nits/editorial comments:

1.       Need to expand LDP when first mentioned.
2.       Section 3.3.1.1 "The multipath data sub-TLV includes information multipath information" delete the first information.
3.       In section 3.3.1.2 "When the Downstream Detailed Mapping TLV in sent in the echo response" should be is sent.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 27 May 2011 04:10:30 +0200

>sometimes necessary to disambiguate recycled TLAs.

Some read such suggestions as indicating they should make paragraph-long
titles. <http://www.rfc-editor.org/rfc-editor/tutorial.latest.pdf>:

  Title

    * Should be thoughtfully chosen

    * No un-expanded abbreviations, except for very well known ones
      (e.g., IP, TCP, HTTP, MIME, MPLS)

    * We like short, snappy titles, but sometimes we get titles like:

        "An alternative to XML Configuration Access Protocol (XCAP)
         for manipulating resource lists and authorization lists,
         Using HTTP extensions for Distributed Authoring and
         Versioning (DAV)"

    * Choose a good abbreviated title for the running header

    * "WebDAV Alternative to XCAP"

They should not do that.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/