Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-00.txt

["Caron, Guy" <[e-mail]>]

Hi ECRIT,

I reviewed the document against the comments I provided 26 July 2016 (see attached) and finds that all except two comments were addressed in this version. The remaining ones are:

c. In Section 5 - uri Not Stored Warning, it is mentioned the 'uriNotStored' is added to the exceptionContainer. I'm no RelaxNG expert but the exceptionContainer doesn't seem to be extended to include uriNotStored in the RelaxNG schema in Section 7; only the basic Exception pattern seems to be defined.

Introduction Section
8. Third paragraph: Add a period at the end of the paragraph, after "revalidation".

Thanks to the author for addressing my comments. I'm looking forward to see this draft, which already went through WGLC, moving forward.

Regards,

Guy

-----Message d'origine-----
De : Ecrit [mailto:[e-mail]] De la part de [e-mail]
Envoyé : 31 octobre 2017 17:45
À : [e-mail]
Cc : [e-mail]
Objet : [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF.

        Title           : Validation of Locations Around a Planned Change
        Author          : Brian Rosen
	Filename        : draft-ietf-ecrit-lost-planned-changes-00.txt
	Pages           : 10
	Date            : 2017-10-30

Abstract:
   This document defines an extension to LoST (RFC5222) that allows a
   planned change to the data in the LoST server to occur.  Records that
   previously were valid will become invalid at a date in the future,
   and new locations will become valid after the date.  The extension
   adds two elements to the <findservice> request: A URI to be used to
   inform the LIS that previously valid locations will be invalid after
   the planned change date, and add a date which requests the server to
   perform validation as of the date specified.  It also adds an
   optional Time-To-Live element to the response, which informs clients
   about the current expected lifetime of the validation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ecrit-lost-planned-changes-00
https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-changes-00


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit

--- Begin Message ---

Hi ECRIT,

I've reviewed this draft and finds the proposed mechanism helpful, well designed and ready for prime time. My review comments are in the sections below where section A is for substantive comments and section B for editorial/cosmetic comments.

Thanks,

Guy

////// START \\\\\\

Section A - Substantive Comments
--------------------------------

a. The document uses the acronym "LI" but it is not defined, expanded or referenced to anywhere. It is not even used in RFC5222. Consider replacing by the generic term "location".

b. In Section 3 - <plannedChange> element, the length limit of the URI is defined as "less than 256 bytes". Consider changing to "256 bytes or less".

c. In Section 5 - uri Not Stored Warning, it is mentioned the 'uriNotStored' is added to the exceptionContainer. I'm no RelaxNG expert but the exceptionContainer doesn't seem to be extended to include uriNotStored in the RelaxNG schema in Section 7; only the basic Exception pattern seems to be defined.

Section B - Editorial/Cosmetic
------------------------------

1. The document uses delimiters (", ', <>) inconsistently when referring to defined strings and terms. Consider using delimiters in a consistent way throughout the document. An option would be to use <> for elements (e.g., <plannedChange>) and request/response (e.g., <findServiceResponse>), single quotes for attributes (e.g., 'asOf') and double quotes for general English terms (e.g., "as of now").

Abstract Section
2. "The extension adds two elements to the <findservice> request: a URI to be used to inform the LIS..." capitalize "a" after the colon.
3. Spell out "TTL" (i.e., "Time-to-Live") and replace "all queriers" with "clients about" so that it reads "It also adds an optional Time-To-Live element to the response, which informs clients about the current expected lifetime of the validation."

Introduction Section
4. First paragraph: Replace "lt;" by "<" in front of "findServiceResponse>".
5. First paragraph: Expand TTL to "Time-to-Live" and put TTL in parenthesis so it would look like "Time-to-Live (TTL)".
6. Second paragraph: Add "-LO" after "PIDF".
7. Second paragraph: Replace "effectivity" (not a word) by "effective".
8. Third paragraph: Add a period at the end of the paragraph, after "revalidation".
9. Sixth paragraph: Replace "lt;" by "<" in front of "findServiceResponse>".

<plannedChange> element Section
10. First paragraph: Capitalize "https".
11. First paragraph: Capitalize "uris" (i.e., "URIs") in the last two sentences of the paragraph.

uri Not Stored Warning Section
12. Title: Capitalize "uri".
13. Capitalize "uri" in the last sentence.

TTL in Response Section
14: Title: Spell-out TTL and put TTL in parenthesis (i.e., "Time-To-Live (TTL)")
15. First paragraph: Add "attribute" after "'expires'" in the sentence starting with "The form of the element is the 'expires'...".
16. First paragraph: Replace "No Cache" and "No Expiration" by "NO-CACHE" and "NO-EXPIRATION" respectively to reflect the actual values as defined in RFC5222.
17. First paragraph: Change "...and MUST NOT be returned in TTL" to "... and MUST NOT be returned in the <ttl> element".
18. Fourth paragraph: Add "value" after TTL in the first sentence.

Security Considerations Section
19. Second paragraph: In the fourth sentence, add "attribute" after "uri" and make byte plural (i.e., "The server MUST validate that the content of the uri attribute sent is syntactically valid and meets the 256 bytes limit")
20. Second paragraph: Capitalize "uri" and "http" in the last sentence.
21: Third paragraph: Delete "when" and capitalize "uri" in the first sentence (i.e., " The mutual authentication between client and server is RECOMMENDED for both the initial <findService> operation that requests storing the URI...")

\\\\\\ END //////

-----Message d'origine-----
De : Ecrit [mailto:[e-mail]] De la part de Roger Marshall
Envoyé : 19 juillet 2016 16:51
À : [e-mail]
Objet : [Ecrit] WGLC Announce: Validation of Locations Around a Planned Change

Today starts a working group last call for:

Validation of Locations Around a Planned Change http://tools.ietf.org/html/draft-ecrit-lost-planned-changes/

Please review the document and send comments to the ECRIT mail list by CoB, July 30, 2016.


Thanks,

Marc & Roger
ECRIT Chairs
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit

NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and/or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media.

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit

--- End Message ---