[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD review of GMPLS SONET documents
Editor's of draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt,
Please remove my name from the authors list on page 1 and the contributors list
on page 12.
Thanks,
Maarten
"Wijnen, Bert (Bert)" wrote:
>
> As AD I reviewed these documents:
>
> draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
> for Proposed Standard
> draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
> for Informational.
>
> Below are my findings that I would like to see addressed
> before I request an IETF Last Call.
>
> For both documents:
>
> 1. Need to reduce the number of authors/people on front page.
> The docs will not be considered again unless you comply
> with the guidelines in section "Author overload" in
> http://www.rfc-editor.org/policy.html
>
> 2. I expect that RFC-Editor will reject the Acronyms in the
> title and abstract. See also the "Choosing titles" and
> "abstract" sections in
> http://www.rfc-editor.org/policy.html
> I believe that the RFC-Editor wants these acronyms expanded:
> SONET, SDH, SONET/SDH
>
> for draft-ietf-ccamp-gmpls-sonet-sdh-05.txt
>
> 1. I think that normative references are needed to documents
> ANSI T1.105 and ITU-T G.707 as I think one cannot understand
> much of this doc if you ignore those ANSI/ITU-T documents.
>
> 2. It seems to me that this document should not reference another
> doc that specifies non-standard extensions. At least, if it
> does so, then maybe once in the iuntroduction is enough.
>
> 3. Last para on page 4.
> I do not understand this. Can you clarify?
>
> 4. On page 6 in the middle I read:
>
> This field is set to one (default value) to indicate that
> exactly one instance of a signal is being requested. Zero is an
> invalid value.
>
> So how does the requestor know requested value has been accepted?
> And what needs the receiver do if the "invalid value zero" is
> requested?
>
> 5. Page 7 in the middle:
>
> Where bit 1 is the low order bit. Others flags are reserved,
> they should be set to zero when sent, and should be ignored
> when received. A flag is set to one to indicate that the
> corresponding transparency is requested.
>
> So how does requestor find out which values have been accepted?
> By the way s/Others flags/Other flags/
>
> 6. I would think that the 1st sentence on page 8 better be
> removed.
>
> 7. Middle of page 10, may want to add refrence to G.707
>
> 8. Page 10 talks about "higher ordered LSP" and "lower ordered LSP"
> Where are those terms defined? May want to explain or reference.
>
> 9. Page 13 talks about "highest part" and "lower part" of a label.
> Might be good to define what you mean by that.
> How about "lowest label"?
>
> 10. You have quite a set of values that you assign in this document.
> For various fields in the SONET/SDH paramters data structure
> and also for various parts of the labels for SONET/SDH.
> The extensions document adds additional (optional) values
> to those fields. You also suggest that other documents could
> add values fro G.832 or G.708.
> How do we keep control over such value assignments/usage?
> Is that something that IANA should control?
>
> 11. In the IANA considerations section you may want to be
> more explicit as to the name-space in which IANA
> needs to make new assignments.
>
> less serious, but once you're at it...
>
> 11. sect 2.1 1st sentence
> s/is organized/are organized/
>
> 12. I see various use of Upper/Lower case for
> Elementary Signal/elementary signal.
> I think it may beuseful to exlain what Elementary
> Signal and Final Signal are.
>
> 13. Last para page 4
> s/node chosen/node has chosen/
>
> 14. I see the use of SONET/SDH and SDH/SONET used arbitrarily
> Would it not be better to choose one form? And let that
> be the same as in the other GMPLS documents?
>
> for draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt
>
> 1. Last para on page 2 seems "marketing" that we do not need.
>
> 2. Top of page 3.
> This document doesn't specify how to implement these features in
> the transmission plane but how to control their usage with a GMPLS
> control plane.
> My question is: Is there any document anywhere that explains
> how to implement in the transmission plane. If yes, then a
> reference to such document would be usefull.
> If not, then how can anyone create interoperable implementations.
> And if they cannot do that, then why is this document useful?
>
> 3. Security considerations.
> I think I would add a ptr to the doc(s) where the security
> mechanisms are described, just as you did for base sonet/sdh doc.
>
> less serious:
>
> 4. I see the use of SONET/SDH and SDH/SONET used arbitrarily
> Would it not be better to choose one form? And let that
> be the same as in the other GMPLS documents?
>
> Thanks,
> Bert
begin:vcard
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies;NA&CPSE
adr:;;Larenseweg 50;Hilversum;;1221 XL;Netherlands
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
fn:Maarten Vissers
end:vcard