[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-05.txt,
As indicated in a discussion on the PWE3 mailing list this week, I don't believe
in putting the names of contributors or editors on a (published) standard. After
approval of a draft standard, the standards organisation agreed with the work
done by the development team and as such has taken over the responsibility of
the resulting standard. Questions on this standard should therefore be directed
to the group responsible for the maintenance of the standard, not to individuals
who happend to work on it. Questions will then be answered by the original
contributors (if still present) or their successors.
For that reason, I request to remove my name from the authors and contributors
lists in the document.
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