Re: [decade] Review of draft-ietf-decade-arch-09

[Konstantinos Pentikousis <[e-mail]>]

Hi Akbar,

  |Thank you very much for the thorough re-review.  Sorry that I have
  |been a bit slow in responding lately because of the summer holidays.

You're most welcome and, of course, no problem.

  |I have embedded some initial RESPONSES below to your first section on
  |"Current inconsistencies between -reqs and -arch".  I will keep
  |reading your "other comments and nits" and get back to you on those
  |later.

Sure.

  |Current inconsistencies between -reqs and -arch
  |-----------------------------------------------
  |With respect to discovery mechanisms, there is a slight divergence
  |between the two documents:
  |  -reqs-08/Sec. 6.9: A mechanism for a Provider to discover and
  |connect to its assigned server MUST be supported.
  |  -arch-09/Sec 5.5: A DECADE-compatible system SHOULD include a
  |discovery mechanism through which clients locate an appropriate
  |server.
  |
  |
  |(1) [AKBAR] OKAY.  THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.

Sounds good.


  |Similarly, -reqs/Sec. 5.4 requires (MUST) the following locally-scoped
  |attributes: TTL, creation timestamp, object size and type. But, -
  |arch/Sec. 6.1.4 recommends (SHOULD): expiration time, object size and
  |type (here explicitly as per RFC 4288, while no such mention is found
  |in -reqs), and "access statistics".
  |
  |(2) [AKBAR]  OKAY, THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.
  |BUT, I THINK IT IS OKAY THAT THERE IS NO REFERENCE TO RFC 4288 AND
  |ACCESS STATS IN REQUIREMENTS, AS THE SPECIFICATION OF THESE CAN BE
  |VIEWED AS A NATURAL 'DESIGN' STEP WHICH IS APPROPRIATE FOR THE
  |ARCHITECTURE I-D.  DO YOU AGREE?

Yes, it's a good resolution.


  |In Sec. 6.1.3.1 the ID mentions "List of associated data objects (with
  |properties)". I guess you need to s/(with properties)/and their
  |attributes/ to keep it in sync with the -reqs ID. That is, you point
  |to -reqs/Sec. 5.4 and -arch/Sec. 6.1.4, not -reqs/Sec. 5.5 ;)
  |
  |(3) [AKBAR] SOMEHOW YOU LOST ME HERE WITH THE DIFFERENT SECTION
  |REFERENCES.  CAN YOU PLEASE RE-WORD YOUR COMMENT?

Sorry about that :) In short, the term "attribute" is used to refer to locally-scoped information stored at the DECADE server (e.g. TTL, creation timestamp, object size and type). This is defined in -reqs/Sec. 5.4. On the other hand, the term "property" appears to relate to application metadata ("application-defined object properties" is -reqs/Sec. 5.5). I like this term differentiation, hence the comment above, as you most likely refer to the former. That's why I proposed s/(with properties)/and their attributes/ in Sec. 6.1.3.1

  |-reqs describes a set of requirements on error handling (Sec. 9
  |mainly, plus tidbits here and there in other sections), while -arch
  |mentions (Sec. 6.2.2) that "Specifics regarding error handling, [...]
  |are deferred to eventual protocol specification." I think this latter
  |approach is better. I expressed this opinion on -reqs/Sec. 9 in my
  |review of that document a couple of weeks ago.
  |
  |(4) [AKBAR]  AS ONE OF THE AUTHORS OF THE ARCHITECTURE I-D, I  HAD
  |AGREED WITH YOUR ORIGINAL SUGGESTION AND THAT IS WHY THE ARCHITECTURE
  |DOCUMENT WAS SIMPLIFIED WRT TO ERROR HANDLING.  I AM NOT AN AUTHOR ON
  |THE REQUIREMENTS I-D AND SO CANNOT SPEAK FOR THEM.  HOWEVER, I DO SEE
  |THAT A CASE COULD BE MADE THAT THESE ERROR CASES BE EXPLICITLY
  |IDENTIFIED IN THE REQUIREMENTS I-D BECAUSE (I IMAGINE) THAT SOME
  |PREVIOUS RESEARCH/THINKING HAS SHOWN THEM TO BE IMPORTANT ENOUGH TO BE
  |LISTED AS EXPLICIT REQUIREMENTS SO THAT WHOEVER SPECIFIES THE PROTOCOL
  |DOES NOT FORGET ABOUT THEM.  THIS AT LEAST HAS BEEN MY PERSONAL
  |EXPERIENCE.  BUT I WILL LET ONE OF THE REQUIREMENTS I-D AUTHORS GIVE
  |THE FINAL WORD ON THIS.

I will wait for others to chime in then.

<snip>

  |(7) [AKBAR] FYI - WE PLAN TO IMPLEMENT YOUR COMMENTS ABOVE AS PART OF
  |ANY UPDATES TO RESOLVE IESG COMMENT.  I  HOPE THAT YOU ARE AMENABLE TO
  |THIS!
 
Sure, no problem.

Have a great weekend,

Kostas