Re: [Gen-art] Gen-ART review of draft-ietf-mpls-tp-gach-gal-04.txt

[Miguel A. Garcia]

Hi Matthew:

Some further discussion in those points that require it. See below.

BOCCI Matthew wrote:

Miguel,

Many thanks for your detailed review. Please see below for responses.

Regards

Matthew

-----Original Message-----
From: Miguel A. Garcia [mailto:miguel.a.gar...@ericsson.com]
Sent: 13 May 2009 09:51
To: BOCCI Matthew; VIGOUREUX MARTIN; swal...@cisco.com;

dw...@cisco.com;

stbry...@cisco.com; ra...@juniper.net; adrian.far...@huawei.com
Cc: mpls-cha...@tools.ietf.org; General Area Review Team
Subject: Gen-ART review of draft-ietf-mpls-tp-gach-gal-04.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-mpls-tp-gach-gal-04.txt
Reviewer: Miguel Garcia <miguel.a.gar...@ericsson.com>
Review Date: 12-May-2005
IETF LC End Date: 14-May-2005
IESG Telechat date: (if known)

Summary: The document is technically ready for publication as a

standards

track RFC, but there is such a number of minor issues that a new

revision

is recommended.

Major issues:

Minor issues:

- Rule of 5. The document lists 6 authors, but the RFC Editor has a
guideline for not exceeding the number of 5 authors. Please read

Section

2.12 of http://www.rfc-editor.org/rfc-editor/instructions2authors.txt

The draft is the result of a merger between two former drafts specifying
the GACH and GAL concepts, respectively. The author's list represents
the editors of those original drafts, some of whom continued to edit the
combine draft.

Usually these drafts with a long list of authors come from the merger of several drafts... Well, I am just saying that the RFC Editor is going to complain. You can select a number of editors, and push some authors to the list of contributors, but from my point of view this will be solve either by you, your AD, or the RFC Editor.

- On Section 4.2.1.1, last paragraph starts:

"The G-ACh message, the ACH or the GAL SHOULD NOT be modified towards

the

targeted destination".

My recommendation is to make the sentence in active voice, there, it

is

easier to see which node has the requirement. So, I suggest something
around these lines:

"LSRs (or whatever node) SHOULD NOT modify...."

OK

And this brings me to another comment... I don't have a clear

explanation

for exceptions to the "SHOULD NOT". Therefore, I believe it should be

a

"MUST NOT".

I agree. In my view, once a G-ACh packet has been sent, no node has
visibility of it unless TTL expires or the GAL is exposed when a label
is popped. If this is at the targeted destination, for example indicated
by an address in an ACH TLV, then we are done. If this is not the
targeted destination, but the node has agreed to process the packet on
that ACH channel, then that processing is out of scope here except to
the extent that clearly the ACH type must be maintained if the packet is
forwarded to another node.

Perhaps you should add this explanation, for example, as a note (indented). Well, it is up to you, but when I read the document I didn't understand the reason for SHOULD NOT rather than MUST NOT, so, any additional information that puts the reader into perspective is welcome.

This comment also applies to the last paragraph of Section 4.2.1.2.

- On Section 4.2.1.2, the last paragraph on page 13 starts with:

"To send a G-ACh message on a control channel..."

That is a horrible long and complicated sentence, which has normative
text. So, please, split the long one into smaller parts, isolating the
normative aspects from the introduction and motivation, so that it can

be

clearly understood which entity MAY do what.

I assume this comment also applies to a similar paragraph in Section
4.2.1.1.  How about the following revisions?:

NEW paragraph in 4.2.1.2:
To send a G-ACh message on a control channel associated to the
Section, the head-end LSR (A) of the Section generates a G-Ach message,
to which it MAY prepend an ACH TLV Header and appropriate ACH TLVs. Next
the LSR adds an ACH. Finally it pushes a GAL LSE.

NEW paragraph in 4.2.1.1:
To send a G-ACh message on the LSP associated control channel,
the LER (A) generates a G-ACh message, to which it MAY prepend an ACH
TLV Header and appropriate ACH TLVs. It then adds an ACH, onto which it
pushes a GAL LSE.  Finally, the LSP Label LSE is pushed onto the
resulting packet.

Very good. And thanks for detecting that this affects to 4.2.1.1 as well.

Thanks,

        Miguel


--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art